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BIRD BUFFER CONFIGURATION - SINGLE 


ITEM 

NO. 

EACH. 

BB TOTAL 

SYSTEM SUB TOTA L 

160A Main Frame 

1 

2250 

2250 


166-2 Printers 

4 

690 

2760 

- 

169-2 Memory (16K) 

1 

2000 

2000 


167 Card Reader 

1 

460 

460 


603 Tape Drives 

4 

550 

2200 


161 On-Line Typewriter 

1 

262 

262 


162-3 Data Synchronizer 

1 

600 

. 600 


Cost per Single BB 

10532 

* 94 , 788 

Computer (Each 10532) 

** 264,028 


STC BLACK ROOM CONFIGURATION - T60A 
USED FOR CLASSIFIED PROJECT 

Approx. 

8 , 000 


SUB 

160A SYSTEM TOTAL 


* 8,000 
** 272,028 
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C. 1 AFSSD has asked if IBM can provide (4) 2250's, Mod. 1 

or Mod.. 2, for use at the Satellite T 0 st Center. They 
have also asked if IBM can provide an interface box to 
interface the 2250 to the CDC 160A. Delivery is required 
as soon as possible. DP Scheduling has indicated that a 2250 
Mod. 1 may be available between March 15 and April 1, 1966. 
FSD has developed a ball park price to the customer for the 
interface box as follows: 

Quantity of 1 $35, 000 

Quantity of 10 $12,000 

Quantity of 40 $ 8, 000 

FSD is trying to trim their schedule to meet the 2250 
schedule. 

Customer wants all equipment GSA but will probably 
accept purchase of the interface box. . 
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PRELIMINARY BRIEF OF EXPECTED RFP FROM AFSSD FOR 
THE BIRD BUFFER SUBSYSTEM 

PART I. Hardware Configuration and Operational Control 

For design purposes, it can be assumed that the primary reason for 
updating the bird buffer subsystem, is to reduce the scope of manual 
control over data flow between the STC and the RTS and to facilitate 
and expedite the issuance of non-programmed commands from the STC 
to the RTS and the orbiting vehicle. 

The present bird buffer subsystem (hereafter call the multiprocessing 
subsystem - See Attachment I) will be replaced by a multiprocessing 
system (See Attachment II) with shared memory. Memory protect will 
be required in order to prevent the destruction of secure data in storage 
due to programming errors and to prevent compromising classified 
information contained the in the data. The multiprocessing system 
will operate under Executive Monitor (EM) control with the EM routing 
data to specified locations in core. The core lock-out feature will 
prevent storage from being addressed in unauthorized (secured)locations. 
Control of the STC data handling system will be centered in the multi¬ 
processing subsystem. Although manual overrides will be provided. 
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all instructions issued to the off-line computers^ the RTS 
computers, and the orbiting vehicle, will pass through and be under 
the management of the EM of the multiprocessing subsystem. 

Data channels from the remote sites will feed directly into the pro¬ 
cessing units under EM control without passing through a Computer 
Communications Converter (CCC) or switching unit. The functions 
presently performed by the CCC and switching unit will be performed 
by the CPU's under EM control. Core-to-core transfer of data 
between the multiprocessing subsystem and the off-line computers 
will be provided in order to utilize the off-line computing capabilities • 
during mission operations. The off-line computers primarily determine 
orbit parameter changes, vehicle command loads, and telemetry 
processing mode tables, based upon predicted latest actual data received 
from the RTS's. "Keys" (Codes - either manual or programmed) can be 
maintained in the multiprocessing subsystem. EM to allow off-line 
computer access to information stored in locked out (secure) storage 
if this information is necessary for computations. 

The multiprocessing subsystem will assume more direct control over 
the RTS/ STC data flow than is presently being exercised by the bird 

(1) NOTE: The off-line computers are those processors which 
perform computational requirements which are considered non-real 
time or non-pass mode oriented. These processors may or may not 
be part of the multiprocessing subsystem, as the customer dictates. 
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buffers. 'The multiprocessing subsystem will operate a set of 
diagnostic programs in the prepass mode to ascertain RTS operation¬ 
al readiness and establish the "real time near" condition. During pass 
mode the multiprocessing subsystem will transmit all non-programmed 
commands and changes to telemetry processing modes, as well as 
programmed instructions, through direct communication with the RTS 
Computers. 

During mission operations, all instructions addressed to the multi¬ 
processing subsystem will originate at the mission center, which will 
have direct communication with the multiprocessing subsystem EM via 
CRT-Keyboard devices. 

The Mission Center displays will be driven directly by the multiprocessing 
subsystem. The displays will be CRT alphanumeric and will have the 
capability to present all data from the RTS’s necessary for mission 
control. The display capability will be such as to allow the selection of 
specific data for display which represent areas of immediate concern or 
areds which indicate a need for immediate change from normal operational 
modes. Based upon displayed information, the mission director will be 
able to issue instructions to the multiprocessing subsystem (through a 
display console) for transmission to the RTS and hence to the orbiting 
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vehicle. The mission director will also be able to direct the off-line 
computers, through the multiprocessor subsystem, to perform orbital 
parameter updates, ephemeris changes, and processing mode changes in 
conjunction with the commands recently issued to the orbiting vehicle 
or the RTS Computers. In this manner, the mission center will be able 
to maintain software configuration control over the STC data handling 
system. 

Software configuration control at the RTS Computers will be maintained 
by the multiprocessing subsystem at the STC. The EM in the multi¬ 
processing subsystem will contain a job table which specifies software 
configuration and processing priority at the RTS. This job table can be 
updated in "real time" by commands from the mission center display 
console. 

The multiprocessing subsystem will be fail-soft and provide a "graceful 
degradation" of mission processing in the event of equipment mal¬ 
function. A voice net from the mission center to the RTS will be 
provided for use in the event of "graceful degradation" mode occurrance, 
or in the necessity of manual override of processing modes during 
normal operations. 

The system will be designed so that all communications with the RTS com¬ 
puters and the off-line computers will pass through the multiprocessing 
subsystem; however, a voice link will be maintained between the STC 

and the RTS in the eventof equipment maulfunction at the STC. 
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SUMMARY 


Features to be provided the STC data handling facility which are not 
now available in the present bird buffer system. 

1. The Bird buffer subsystem will be replaced 

by a multiprocessing system utilizing shared memory 
with memory protect. 

2. The multiprocessing subsystem will automatic¬ 
ally ascertain the operational readiness of the remote 
sites and maintain configuration control and processing 
priority of the RTS computer programs. 

3. Switching hardware presently utilized at the bird 
buffers will be deleted and the RTS data channels can 

be selected by the EM of the multiprocessing system for 
processing and/or storage. 

4. The real-time multiprocessing subsystem CPU’s 
will have direct communication with the off-line CPU's 
during all phases of operations. If required, a method 
will be provided to allow the off-line CPU's access to 
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data stored in secure locations, under the scrutiny 
of the executive monitor and/or a manual Control 
Console. 

5. All displays for the Mission Center (Mission 
director station) will be directly driven by the real¬ 
time multiprocessing subsystem CPU's. 

6. The displays will be CRT-Alpha-numeric and 
will display all information necessary for the system 
controller to maintain control of all missions. Display 
consoles and on-line,keyboards will be provided for 
direct communication back to the multiprocessing 
subsystem. There I/O equipments will be utilized 

by the system controller to issue non-programmed 
Commands and processing mode changes through the 
multiprocessing subsystem to the RTS Computers. 

These instructions will be based upon decisions made 
after viewing the CRT displayed information. 

7. The multiprocessing subsystem will be fail-soft 
and provide a "graceful degradation" of mission pro¬ 
cessing in the event of equipment malfunction. A voice 
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net from the mission center to the RTS will be provided for use in 
the event of "graceful degradation" mode occurrance. 
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PRESENT BIRD BUFFER SUB-SYSTEM 

~ ' I Voice Command' 

i | To SOC at RTS 
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PROPOSED BIRD BUFFER SUBSYSTEM CONFIGURATION 
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PRELIMINARY BRIEF OF EXPECTED RFP FROM AFSSD FOR 
THE BIRD BUFFER SUBSYSTEM 

PART II. Software 

The programming system will be integrated for the new STC multiprocessing 
subsystem (MPS). It will include an Executive Monitor, assembled library 
routines, input/output control program (all peripherals including the 3600's), 
a JOVIAL Compiler, an assembler and a loader. All multiprocessing sub¬ 
system programs must operate under control of the Executive Monitor (EM). 

# Executive Monitor Characteristics 

The EM will control operations on all multiprocessing 
CPU's and will permit easy transition between STC modes 
of operation by previously scheduled information and modes 
of operation dictated by manual operator intervention. 
Information on interrupted in-^process jobs will be 
preserved so that the processing may be completed at a 
more propitious time. The EM should be designed so as 
to guarantee the following: 

a) Standard communications between the CPU's and 
any operator-user. 

b) Real-time access to the MPS library programs to 
take full advantage of written, tested code. 


Section 3. 3. 2 


Page C. 2/10 
12/15/65 




- 2 - 


IBM CONFIDENTIAL 


c) I/O assignment tables with automatic handling 
of hardware locations and flags associated with 
traps, interrupts and special registers. 

d) Standard linkage from object programs and 
system programs to commonly used subroutines 
within the EM. 

e) Task assignment to available processors in 
prioritized order, using a multi-processing 
philosophy. 

f) Provision of a job execution status report upon 
request. 

g) Standard job accounting and record keeping 
routines for MPS operations. 

h) Direct communication with the off-line 3600’s in 
order to utilize the additional computational 
capabilities. 

Multiprocessor Characteristics 

A multiplicity of program execution is heduled by the EM 
which also controls the time-sharing of I/O, memory, and 
processors. This should be accomplished by use of a job 
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table specifying a list of current programs and their 
status, and a memory map specifying available, in 
use, or unavailable (secured) areas. The EM will 
also maintain tables containing file information and 
control usage of each I/O device. Accordingly, a single 
program should be able to be executed simultaneously by 
the two processors utilizing different sets of data. The 
total multiprocessing system should appears as one 
computer to the programmer. 

Compiler - EM Relationship 

Whenever a program has been read into memory for 
execution, specific program points should enable program 
segments to operate in parallel. When these points are 
reached, the EM is entered. The action of the EM at these 
entrance points depends on the type of executive call made. 
The assembler or compiler must be able to accept the 
imperative statements of the programmer which direct the 
EM to a course of action and translate these statements into 
entrance instructions for the EM. In addition, the assembler 
must construct all other entrance parameters and a job 
table. 
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Job Table 

A Complete set of tables should be loaded by the EM 
to guarantee that the monitor has knowledge of all 
possible parallel processing at that moment. 

System Design 

Debugging on simulation tools must be available, as 
well as the ability to run the program totally on one CPU. 
The compiler should not demand that the task to be 
performed is performed on multiple processors. 

Scheduled tasks should be able to be changed in real-time. 
New tasks should be able to be defined at any time. 
Memory conflicts should be automatically solved when 
CPU's are attempting to get to the same memory module. 

Central I/O Control Program 

Input and Output to the CPU's will be controlled by a 
Central I/O control program (IOC) which is, of course, 
controlled by the EM. The IOC will: 

a) Control the reading/writing of records 

b) Provide for overlapping I/O reading, writing and 
computing. 
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c) Perform, automatic blocking and deblocking of 
disc file records. 

d) Check reading and writing errors and correct 
program corrigible errors. Error analysis should be 
attempted in all cases. 

e) Provide sequential and random processing of data 
on the disc files. 

f) Schedule the use of disc file arms including auto¬ 
matic handling of arm. failure 

g) Alter I/O unit assignments if necessary at execution 
time by means of manual intervention. 

h) Insure that MPS disk packs are properly formatted and 
contain standard labels. Labels should be written upon 
output and read on input. 

i) Check/Process end-of-data file conditions. 

j) Write recovery-flags to facilitate restart recovery. 

The IOC will provide for standard operator program communications. It 
must be accessed operationally by on-system programs by means of 
appropriate assembler/compiler MACROS. No program should be able 
to initiate I/O directlt without the use of MACRO’S. Execution of MACRO- 
constructed instructions will necessitate entry to the Executive, and the 
Executive will control and monitor the IOC. 
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• Storage Protection 

A storage protection feature shall be provieed to preserve 
a program if another erroneously attempts to store over it, 
whether the storage medium is core or disc. Storage 
operations from either a CPU or Channel will be subject to 
this feature. 

Programs should be self-checking with program or machine 
error producing a unique interrupt condition so that the 
cause of the error may be easily ascertained. 

Software must automatically initiate corrective action to the 
fullest possible extent. 

Examples of necessary and desirable interrupt conditions are as follows: 

A. Internal (Processor Generated) Interrupts: 

1) Illegal instruction executed 

2) Halt instruction executed 

3) Arithmetic overflow 

4) Real-time clock overflow 

5) Attempt to write out of bounds 

6) Parity error from memory 

7) Interrupt a computer 

8) Initiate I/O 

9) Store interrupt mask register 
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with just one processor functioning. This requiremen must specifically 
guarantee that: 

a) I/O activities can be initiated on any channel from any CPU. 

b) The EM is not to be permanently associated with any of 
CPU's, nor does it require the complete attention of a whole CPU. 

c) CPU's must respond to all types of interrupts, including I/O 
interrupts. To avoid duplicate handling of I/O interrupts, one CPU 
could be designated to receive such interrupts at i ny one time. 

d) Programs must be capable to operate correctly on either CPU, or 

if both are available. If a system component fails during task execution, 
the EM must be ableto sense the condition, reassign I/O units, and 
continue operations. If necessary, it should be able to take steps to 
service tasks in a degraded mode. 

In particular, if any CPU fails, the EM must reassign its current task to one-of the 
other CPU's*. Possible m ethods for notifying the CPU's that another has mal¬ 
functioned might be: - 

1. A unique interrupt signal is generated, T>y a malfunction which 
interrupts the other CPU.S 
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U 

2. The malfunction makes a status register - addi essable by one of the 
other CPlTfs and tested each time the EM is operate d therein - to 
change state. 

NOTE: In either case, the EM when operated by the still-functioning CPU 
should take note, institute recovery action, and output appropriate alarm 
messages. 

As mentioned earlier, the . CPU's must be able to receive and act on I/O 
interruptions, but only one CPU is so designated at any one time. When the 
EM schedules tasks to a CPU, or attempts to find tasks and fails, it determines 
which CPU has the lowest priority activity and selects that one to receive 1/O 
interruptions, until the next task assignment is considered, if a malfunction 
occurs in the designated CPU, the EM should automatically switch I/O 
interrupts to an operable CPU. 

If component failure is so serious that full operation cannot continue, the 
Executive must decide which functions to perform, and delete. It is conceivable 
that the type of failure would determine which tasks would be performed; 
however, in general, selecting the tasks to be retained would be done: 1) on 
the basis of the predetermined priority associated with each task, or, 2) by shift 
ing some ofthe tasks normally performed at the multiprocessing CPU to the off Tine 
'*■ computers, or, 3) 

Section 3. 3. 2 


Page C. 2/17 
12/15/65 




-9- 


IBM CONFIDENTIAL 


by a combination of 1) and 2). 

Job Accounting 

Standard job-accounting and record-keeping programs will be provided. 
The Executive will account for elapsed time on each CPU and on each 
I/O device according to the Program (Satellite Project)office. The job 
accounting code will be provided at the same time as the job request is 
made. During vehicle-related activity, the vehicle number may serve to 
correlate to the appropriate accounting code. 
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PRELIMINARY BRIEF OF EXPECTED RFP FROM AFSSD FOR 
THE BIRD BUFFER SUBSYSTEM. 

PART III - DISPLAY 

The Mission Center is currently the central control point at the STC. it 
is in this center that the switches and displays used to monitor the STC 
data handling functions ate located. This position is operationally manned 
by six personnel during real time functions. Actions are initiated via 
voice net to the Bird Buffer subsystem operators and, if necessary, to 
the SdC operators at the remote tracking sites. The intent of the expected 
RFP will be to establish direct control of the Bird Buffer subsystem from 
the display consoles in the Mission Center. Instructions to the remote 
site computers will pass through the Bird Buffer subsystem and be under 
control of the Executive Monitor. The voice net will be maintained for 
emergency communications. 

OPERATIONS 

A Station Control and Display console (SCDC) will replace the current 
Mission Center displays. The SCDC configuration will consist of three 
IBM 2250 Display and Input (DI) devices. The 2250's will not be dedicated 
but will be provided the capability for "dialing" the information desired 
for display. 
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The SCDC will enable the operators of the mission center to perform 
the following functions: 

1) Assess the mission need for particuar telemetry 
processing modes 

2) Configure STC and RTS Computer programs to 
accomplish the needs expressed in 1). 

3) Control all computer processing via the DI keyboard . 

4) Monitor all computer-output data display, either in an 
operational or diagnostic mode. 

5) Provide real time data analysis and control. 

6) Initiate non-programmed commands which are 
necessitated due to real time conditions 

UTILIZATION 

Computer Control Control of all computer operations may becontrolled 
by the 2250 input keyboard, as well as the on-line typewriter. (At any 
time, the 2250 operator can lock-out the on-line typewriter as an input 
device to the computer). 

Display Makeup . Depending on the type of processing to be performed, 
the CPU will generate display tables and input drivers. The tables may 
. be filled with overlay and/or mission data, and can be selected at ary 

ri "'' v - 

"V *■ V; • ; 

time by any of the 2250 DI's. In effect, there is no dedicated 2250 DI 
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for any operation, and no concrete or unchangeable total display. The 
operator can build and change the display in real time (within the 
constraints of the current softwars system) to implement his real time 
analyses of data and command control decision. Input drivers can be 
called in real time if necessary to effect computer driven activities 
(i. e. digital commanding). 

Retention of Data . In addition to data display in real time, the 22 50 
operators will be able to retain summary information on the 2250's, 
such as Commands transmitted during PASS, or issue instructions for 
certain data to be retained "Hard Copy" on the shared on-line printer. 

Fail Safe (abbreviated) Operation . In the event of failure of one 2250, 
the remaining 2250 can support the complete station operation in an 
abbreviated mode. Utilizing the table philosophy noted eariler, this 
mode may not be a degraded one. 

Lockout Feature. Utilizing the 2250 DI's and input driven methods out¬ 
lined, it is impossible to initiate erroneous commands. Keyboard 
inputs in the configuration and sequence outlined by the driver will be 
the only ones accepted, thus preventing the transmission of erroneous 
commands to the STC or RTS Computers. 

DESIGN . 

The primary design principle employed is to provide the means to adapt 

Section-3! 3. 2 Page C. 2/21 

12/15/65 




IBM CONFIDENTIAL 


-4- 

the various missions, or increased operational Command and Control 
requirements through computer program software, rather than through 
hardware modifications. Thus, with a sufficiency of computer programs 
the MiissionCenter operations will be able to maintain real time mission 
control. 

A secondary principal employed is the retention of minimum analog and/or 

«£ .. 

non-computer driven displays to oiable fail-safe station operation if 
the entire data procesing system is unavailable. As the "fail-soft" 
reliability of the total IBM STC configuration is proven, all essential 
functions of the SC DC could be moved to the 2250 DI's. 

IMPLEMENTATION 

Three 2250 model 2 display units will be located in the mission center. 

The 2250's will connect to the MPS through a 2840 Display Control unit. 

(see Attachment I) . The 2840 offers an 8, 192 byte buffer in which to 
store images for regeneration purposes. The use of the buffer allows the 
display unit to operate concurrently with the MPS, freeing main 
storage for other functions. The images are transferred from main 
storage to the buffer only once, thus saving storage cycles and channel 
time. The buffer is generally used with the character generator and 
alphameric keyboard to edit or assemble messages before they are 
transferred to the main computer storage. The portion of buffer 
storage to be used for any display unit is program-assignable and can 
be varied in size under program control. 
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The MPS Connection to the 2840 can be to either a multiplexor or 
a selector channel. Attachment to the selector channel is preferable, 
because of the higher data rates. 

When the channel is polling for units having status information, the 
2840 services the 2250, Mod. 2 , units on a priority basis. 
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Machine 

Feature 

Description 

Unit 

Price 

Q3SL> 

MAC 

MAC Total 

7251-4 

Storage Element-64KW-14 OK 

3,500 

2 

7,000 

CPU's etc. 

7251-3 

Storage Element-32KW-74K 

1,850 

0 

0 

41,825 

7201-1 

Computing Element-190K 

4,750 

4 

19,000 

x 115% 

7231-2 

I/O Control Element-21 IK 

5,275 

3 

15,825 

48,098 

2911-x 

Switching Unit 

800 

6 

4,800 

Switching 

2925-x 

Switching Unit 

1,500 

1 

1,500 

Units 

RPQ 

Include CCR's in 2925 

500 

1 

500 

6,800 

2814-2 

Display Switching Unit 

125 

1 

125 

Displays 

2840-1 

Display Control 

1,100 

5 

5,500 


3351 

Display Multiplexor 

50 

5 

250 


1003 

Absolute Vectors 

125 

5 

625 


1499 

Buffer (Add'l 8K for 16K total) 

400 

5 

2,000 


2250-2 

Display Unit 

350 

15 

5,250 


1001 

Absolute Vectors 

225 

5 

1,125 


1245 

Alphameric Keyboard 

50 

15 

750 


4875 

Light Pen 

75 

5 

375 


5855 

Prgmd Function Keyboard 

100 

5 

500 

16,500 

2803-1 

Mag. Tape Control 

650 

2 

1,300 

Mag. Tape 

7125 

7 Track Compatibility 

50 

2 

100 


6148 

Remote Switch Attach 

n/c 

2 

0 


2401-2 

Magnetic Tape Unit 

485 

6 

2.910 

4,310 

2314-2 

Direct Access Storage 

3,500 

3 

10,500 

Disk 

8170 

Two Channel Switch 

140 

3 

420 

10,920 

2821-1 

Printer Control Unit 

970 

2 

1,940 

Printers, 

1990 

Column Binary 

100 

2 

200 

Readers, 

1443-N1 

Printer (240 LPM) 

875 

4 

3,500 

Consoles 

1403-N1 

Printer (1100 LPM) 

900 

2 

1,800 


2540-1 

Card Read Punch 

660 

2 

1,320 


1052-7 

Printer- Keyboard 

65 

2 

130 


7265-2 

System Console 

1,200 

1 

1,200 

10,090 

7289 

Peripheral Adapter Unit 

3,000 

2 

6,000 

Comm. 

RPQ 

Binary Sync Data Adapter 

100 

24 

2,400 


RPQ 

TTY Adapter 

100 

8 

800 


RPQ 

1052 Adapter 

100 

1 

100 

9,300 

1827 

Data Control Unit 

190 

1 

190 

Voice Line 

3289 

Dig - Ana Out- Ba s ic 

70 

1 

70 

Switching 

3296 

Dig Out Control 

15 

1 

15 

3295 

Dig Out Adapter 

15 

3 

45 


3612 

Eco Grp of 16 Pts 

20 

10 

200 


RPQ 

Voice Line Switch Box 

300 

1 

300 


RPQ 

Voice Line Adapter 

20 

60 

1,200 

2.020 


Sec. 3.3.2 

Page C.2/26 (3/18/66) 
Replaces 2/11/66 


108,038 



IBM CONFIDENTIAL 


UNIVAC COMPETITION FOR BIRD BUFFER 
Equipment Priced is Rough Equivalent of 
9020 Configuration on Page C. 2/25 and 26 


UNIVAC 494 

The attached price list represents a UNIVAC 494 Multiprocessor 
configuration. The 494 memory is limited to 5 ports which can 
accommodate any combination of processors and/or I/O controllers. 
Channels are standard with the processor but may be ignored in 
favor of the I/O Controller. This configuration, therefore, repre¬ 
sents a 3-processor, 2-controller configuration with sufficient 
two-way switching on the I/O components. 
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UNIVAC 494 


Characteristics 


Storage: 

Cycle Time: 
Word Length: 
Channels: 

Instructions: 

DASD Storage: 

Addressing: 


Memory Protect: 


16 to 131 K words 

750 ns/word (375 ns/wd overlap) 

30 binary bits + 2 parity bits 

12 - 250 KC standard (max. 24) 

555 KC available. No peripheral 
addressing, one device per channel. 

D.P. Fixed and Floating-point 
and Decimal are- standard 

Various Drums - 2311 and 2321 
offered. 

15-bit addressing to a 32K bank, 
relative Index Register designates 
active 32K bank Half-words are 
addressable. 

Standard in 64-word increments 


Instruction Times: 


Add 

750 ns 

Mult. 

7.3 us 

Divide 

7.4 us 

Fit. Add 

3.2 us 

Fit. Mult. 

12.5 us 

Fit. Divide 

13.0 us 
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UNIVAC 494 


Machine 


Unit 



Feature 

Description 

Price 

Oty 

MAC 

5010-01 

Card Control & Synch 

750 

2 

1,500 

0706-00 

Card Reader, 800/900 

380 

2 

760 

0600-00 

Card Punch, 300 CPM 

665 

2 

1,330 

8120-02 

Printer Control & Synch 

750 

2 

1,500 

0751-00 

Printer, 700/922 LPM 

800 

4 

3,200 

0900-05 

Comm. Term. Module Cont. 

650 

2 

1,300 

0901-04 

Low Speed Line Adapter 

60 

4 

240 

0903-02 

High Speed Line Adapter 

90 

12 

1,080 

2250 

EQUIVALENT DISPLAY 



16,500 

1827 

VOICE LINE SWITCH EQUIV, 

» 


2,000 

5008-16 

UNISERVO VIIIC Control 

1,450 

2 

2,900 


and Synch 




0859-00 

UNISERVO VIIC 

800 

6 

4,800 

3012-99 

Processing Unit 

9,500 

3 

28,500 

7005-95 

Memory - 13IK 

20,000 

1 

20,000 

0xxx-02 

I/O Controller 

4,000 

2 

8,000 

F0xx-08 

I/O Chan. (Add'l 4) 

500 

4 

2,000 

0xxx-00 

Multi-Mem Adapter Basic 

500 

4 

2,000 

0xxx-01 

Multi-Mem Adapter Add'l. 

235 

4 

940 

0955-02 

Multi-Processor Adapter 

425 

6 

2,550 

7304-01 

FH-880 Drum 

2,000 

1 

2,000 

8103-03 

FH-880 Control & Synch 

1,420 

1 

1,420 

2314-2 

EQUIVALENT DISK 



10,920 


115,440 
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UNIVAC competition for Bird Buffer 

Equipment priced is rough equivalent 
of 9020 configuration on page C.2/25 
and 26. 


UNIVAC 1108 

The attached represents a triplex UNIVAC 1108 multiprocessor 
configuration. UNIVAC has an 1107 and one 1108 installed at 
Lockheed Missiles for a security project associated with the Satellite 
Control Facility. We estimate that this system has roughly six 
times the potential performance of the 9020. We have used IBM 
2250's and 2314's on Sperry's equipment, since they have an IBM 
standard interface. 
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1108 CONFIGURATION FOR BIRD BUFFER 


Core Storage 
3/4 us 
36 bit + 2 
65K words 
10 tail 


Core Storage 
3/4 us 
36 bit + 2 
65K words 
10 tail 


Core Storage 
3/4 us 
36 bit + 2 
65K words 
10 tail 


' 1108 CPU N 

128 wds 125 ns 
15 index 
16 accumulator 
v 3/4 -»1.5 us addy 


10 Tail Memories 


A 1108 CPU 
128 wds 125 ns 
15 index 
16 accumulator 
y3/4-> 1.5 us add 


f 1108 CPU 
128 wds 125 ns 
15 index 
16 accumulator 
*3/4 ->1.5 us add , 


Communi¬ 

cation 

Estimate 


Drum 


Files 


4/0 Controller 
16 Channels 


Magnetic Tape 


/ FH432 Drum/ 
1.6 million char, 
4.25 ms access 
X.440KC tfr 7 


Four 

IBM 

2314’s 


Control 
RR or 
RW 


4/0 Controller' 
* 16 Channels 


me ^ 

7 bit 
62.5 KC, 


'I/O Controller 
, 16 Channels 


Displays, card readers 
and printers as on 
Page C.2/25, Sect. 3.3.2 
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Unit 

Total 

Unit 

Total 

Ot£. 

Description 

Rental 

Rental 

Purchase 

Purchase 

3 

1108 CPU's 3011-99 $15,500 

$46,500 

$651,000 

$1,953,000 

3 

Core Stg. 65K wds, 2 banks 

10,000 

30,000 

420,000 

1,260,000 

3 

Basic I/O controller & 4 ch. 

4,000 

12,000 

168,000 

404,000 

9 

Additional I/O channels (4) 

500 

4,500 

21,000 

189,000 

3 

Multimemory adapter (5 tails) 

500 

1,500 

21,000 

63,000 

3 

Additional memory tails 

235 

675 

9,870 

29,610 

3 

Drum (FH432) & controller 

3,000 

9,000 

120,000 

360,000 

2 

Uni servo IIIC tape controls 

1,350 

2,700 

64,800 

139,600 

6 

Uni servo IIIC tapes 

750 

4,500 

36,500 

219,000 

2 

High speed printer controls 

750 

1,500 

34,275 

68,550 

4 

High speed printers 

800 

3,200 

36,000 

144,000 

2 

Reader/Punch Control 

750 

1,500 

33,750 

67,500 

2 

800 CPM readers 

380 

760 

15,200 

30,400 

2 

300 CPM punch 

665 

1,330 

26,600 

53,200 

(Est.) 

Multiple I/O interfaces to 






three I/O control units 

— 

2,000 

— 

84,000 


SUB TOTALS 

121,665 


$5,064,860 


Displays 

—— 


11,325 



IBM 2250‘s & 2840‘s 






from page C.2/26 





3 

SR 2840 adapters 

300 

900 

13,500 

40,500 

4 

IBM 2314’s 

5,250 

21,000 



4 

Two channel switch 

140 

560 



4 

SR 2314 adapters on 1108 

300 

1,200 

13,500 



2 

Communications 

0900-05 comm, terminal cost 

650 

1,300 

25,000 

50,000 

4 

Low speed line adapters 

60 

240 

2,400 

9,600 

2 

High speed line adapters 

90 

1,080 

3,600 

43,200 


TOTALS $45,970 $147,945 $1,727,320 $5,208,160 
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D. PROBLEM AREAS 

Resolution to the security of classified data at the Bird 
Buffer installation is a problem. The following paper has been 
submitted to Aerospace/SSD as a possible solution. 
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THE SECURITY OF INFORMATION 
IN A MULTIPROCESSING SYSTEM 


12 November 1965 

This data shall not be disclosed outside the 
Government or Aerospace Corporation, or 
be duplicated, used, or disclosed in whole 
or in part for any purpose other than evaluation. 
This restruction does not limit Aerospace 
Corporation or the Government’s right to use 
information contained in such data if it is 
obtained from another source. 
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INTRODUCTION 


When secure information is to be processed in a multiprocessing 
system, the historical methods of achieving the necessary security via 
isolating the various programs and data by physical equipment separation 
can no longer be applied. By its very nature, a multiprocessing system 
implies commonality of equipment and sharing of acilities. This 
centralization of computing equipment does not, however, mean that 
the security of the information to be processed in such a facility will 
be compromised. The architecture of IBM's System/360 permits the 
establishment of a combined hardware/software system design which 
will provide the requisite security while retaining the advantages which 
accrue from multiprocessing. 

During the design of System/360, the need for assuring the security 
of data and programs was recognized. The primary reasons were 
to obtain privacy of data and records where needed, and to permit 
the testing of programs by restricting them to specific regions of memory, 
thereby precluding accidental or deliberate destruction of other data 
during the testing period. Two primary techniques were built into 
System/360 to answer this need: 

1. Instructions which cause a change in system status or the 
system control parameters, which alter storage protection 
arrangements, or which perform input/output operations, 
are considered privileged. These instructions may be 
performed only by a processor designated as being in a 
supervisor mode. 

2. All core storage attached to the system has a storage 
protection feature. This feature always operates. It 
precludes access to any storage location without presentation 
of the proper storage key. The assignment of storage keys 
can be done only by privileged instructions executed by a 
processor in the supervisor mode. 

These techniques will be examined in greater detail. It will be 
shown that a secure environment can be established for the processing 
of classified information in a multiprocessing system. 
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THE PROGRAM STATUS WORD AND PRIVILEGED INSTRUCTIONS 


The Program Status Word (PSW) is a fundamental part of the 
architecture of System/360. The PSW is contained in each computer. 

It is the storage register for various types of control information 
which reflects the status of the system and the conditions under which 
a program is being executed. Two items in the PSW are of particular 
interest to this discussion, the supervisor bit and the storage key. 

Each computer operates in either the supervisor state or the 
problem state. The state is specified by the supervisor bit in the PSW. 
When it is in the problem state, the machine can execute all necessary 
computing and data processing-type instructions. However, instructions 
which have to do with I/O, storage protection, or instructions which 
can alter the control fields of the PSW are privileged instructions , and 
are not valid when the machine is in the problem state. An attempt 
to execute one of these privileged instructions when in the problem 
state will result in suppression of the instruction and an interruption 
to a supervisor program. 

Each time a reference is made to core storage, the computer 
must present a storage key for access. (The details of the operation 
of storage protection are covered in a later section of this paper.) 

The storage key used by the computer is that one which is contained 
in the PSW. 

Once a PSW has been established, the computer is restricted to 
a specific region of storage (defined by the storage key) and operates 
in either supervisor or problem state as specified by the PSW. The 
computer will remain in this status until the PSW has been changed. 

A PSW can be changed in only three ways: 

1. Through the use of computer instructions. Each instruction 
which can change the supervisor bit or storage key, however, 
is a privileged instruction. A computer must be in the 
supervisor state to execute these instructions. 

2. By a program interruption. A program interruption is 
accomplished by replacing the current PSW with a new one. 

This new PSW is fetched from a specific area of storage 
called the Preferential Storage Area. 
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In practice, this area of storage is used only by the supervisor 
program and would be under a storage key reserved only 
for the supervisor^ use. Thus, a machine which does not 
have the proper storage key in its PSW could not enter that 
area of storage to modify a PSW to be fetched on a subsequent 
interruption. 

3. By an initial program loading operation. The initial program 
load is done from a control console. When exercised, it 
places in the machine a new PSW which will then control the 
system until the program being read in changes it. This 
PSW is obtained from the input device used for loading. This 
presents no hazard to security of data since there are two 
controls. First, the recording medium used on the input 
device can be controlled. Second, the actual operation of 
the loading function can be placed under console lock and 
key, and the key retained by a designated authority. 

Thus, modification of the PSW, which is vital to the establishment 
of a secure data environment, can be rigidly controlled. Users operating 
in the problem state cannot modify their PSW to permit unauthorized 
access to compartmented data, or to permit execution of privileged 
instructions. 
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STORAGE PROTECTION 

For the purpose of storage protection in System/360, all of core 
storage may be considered to be divided into blocks of 2048 bytes 
(byte = 8 bits plus 1 parity bit). These blocks are located on address 
boundaries which are multiples of 2048. With each block of 2048 
bytes, there is associated one of 16 possible storage keys which are 
contained in a separate part of the storage unit. 

Whenever a reference is made to a storage location, the accessing 
element must present a storage key along with the address. The 
storage unit will read out the storage key associated with the block which 
contains the referenced location. A comparison is made between the 
key contained in storage with the key presented by the accessing element. 

If the accessing element wishes to alter the referenced location, 
then the keys must match. If they do not, storage protection is violated 
and a program interruption to the supervisor program occurs. The 
data in the referenced location is not altered. The execution of the 
instruction or I/O operation is suppressed or terminated. 

If the accessing element does not wish to alter the location in 
storage but only wishes to read it, an option is available. At the time 
that the storage key for the location was established by the supervisor 
program, the key could be set to specify "fetch protection" also. If 
the key in storage is set for fetch protection also, the key presented 
by the accessing element must match the storage key or protection is 
violated for a read operation. Again, for this situation, a program 
interruption to the supervisor program occurs. Data from the refer¬ 
enced location will not be transferred to addressable locations in the 
accessing elements, nor will it be written on any output medium. 

This option on protection for reading of data permits either total pro¬ 
tection (read or write protection), or the flexibility for sharing of 
areas where it may be desirable for several programs to read some 
common data without allowing alteration of that data (write protection). 

A "master key" (specifically zero) is provided for use by the 
supervisor program. Such a capability allows the supervisor to alter 
or override storage keys to restructure the storage area. 
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The storage keys contained in the storage unit each have a parity 
bit associated with them. The keys presented by accessing elements 
are also protected by parity bits. Single failures in either the accessing 
elements key or the storage elements key will be detected and signaled. 
Interruption to the supervisor program is done immediately on detection 
of these failures. 

The storage protection in System/360 thus permits the isolation 
of data and programs in storage under a unique storage key. Access 
to this area is not possible unless the correct key is presented. Single 
failures of the equipment will be detected to preclude the possibility 
of an incorrect key being altered by a failure to a correct key. 
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A SYSTEM CONFIGURATION DESCRIPTION 

A more cohesive understanding of the handling of secure data 
in a multiprocessing system can be gained from an examination of 
an actual system configuration. Figure 1 is a block diagram of a 
system which could be used for real-time data processing with varying 
security and need-to-know requirements. The system shown in 
Figure 1 is, of course, only one form that a multiprocessing system 
could take. Each element in the computing system is duplicated, 
providing a back-up capability in the event of an element failure. 

The modularity of the system permits other units (storage, computer, 
or I/O) to be added should an increase in capacity be required. 

Figure 1 has omitted for clarity any of the conventional I/O devices 
such as tapes, disks, printers, etc. These may be attached to the 
I/O control units as desired. 

The computing elements provide the computational and data 
processing capability for the system. In addition, the computing elements 
provide special facilities for system control. Storage is provided in 
modular units. The interface with the peripheral devices and communi¬ 
cation links is provided by the I/O control units. 

The computing elements do not have I/O capability. All I/O 
operations are initiated by a computer which informs the I/O control 
unit of the type of I/O operation desired and the device it wishes to 
activate. The computer then proceeds with its normal instruction 
stream. The I/O control unit performs all data routing and control 
functions necessary to perform the I/O operation. Each I/O control 
unit can access any location in the storage complex, as can each 
computing element. I/O operations are also monitored by the storage 
protection hardware. 

Multiprocessing offers the ability to program a system in a very 
flexible manner. Since there is complete symmetry in the system, 
i. e. , the computers are identical, all storage is available to all 
accessing elements, etc. To achieve the potential benefits of multi¬ 
processing, the computing elements would not be "dedicated" in the 
sense that each one always performs a specific function. The 
preferred approach is to treat computers merely as resources. 

Each is assigned the next task in the problem as it becomes available. 
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Such a concept requires the symmetry of the system shown in Figure 1. 
With this approach, any user may avail himself of the complete 
resources of the system. Also, the modularity of the equipment makes 
growth a relatively simple problem. If system programs are written 
initially to take cognizance of the system resources available and to 
operate accordingly, then an increase in resources will cause no 
great inconvenience to established programs. 
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PROCESSING OF SECURE DATA 

The foregoing discussions on the various aspects of assuring 
the security of data in a multiprocessing environment can be best 
appreciated in the context of a hypothetical procedure which could 
be used. A procedure will now be discussed which will show how 
these various features can be integrated. 

It is presumed that data is being received from the communication 
links and that the data from each source must be isolated into data 
groups and protected. There may be several of these communication 
links active at one time. It is also assumed that separate problem 
programs will be used to manipulate and process each data group 
and that these programs will in general be allowed access to only 
that data group which is of specific interest to it. It is further assumed 
that there may be occasions where it is desired that a problem program 
have access to several data groups. 

Control of the entire system would be vested in a supervisor 
program. This program would perform the following functions: 

1. Structure storage and allocate system resources for each 
user program. 

2. Schedule and dispatch task programs. 

3. Respond to all inquiries from terminals concerning access 
to stored data and requests for specific programs to be run. 

4. Execute and control all program interruptions. 

5. Perform all input/output operations. 

This supervisor program would be resident in one storage unit. 
Either unit could be used. To preclude a system breakdown in the event 
of a core storage failure, the supervisor program would also be stored 
on an off-line medium (disk, tapes). To enable quick recovery, a boot¬ 
strap calling sequence would be retained in the alternate core storage 
unit. Thus, in the event that a core failure is encountered, provision 
is made to automatically interrupt into the alternate core storage to 
begin recovery operations. 
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All supervisor program space would be protected by a unique 
storage key. At the time of initial program loading, the first task 
of the supervisor program would be to structure the necessary super¬ 
visor storage areas with the storage key specified. From that point, 
only a program with this key can operate in those areas. This key 
is never assigned to any program except the supervisor. 

From the time of initial program loading (when a specific computer 
is assigned to perform the load) the supervisor may be run by either 
computer as needed. This is an important concept of multiprocessing. 
The control is really the program. The actual machine which executes 
it will vary from time to time. This presents no security problem, 
since a machine must execute a program interruption to run the 
supervisor program. The interruption service programs are, in 
fact, a part of the supervisor and are stored under the supervisor key. 
Hence, a machine cannot gain access to this area while in the problem 
state. The supervisor program should be largely re-entrant (i. e. , 
no modifications of the program should be permitted) to minimize the 
need for control of sequential execution by both machines. 

The supervisor would establish distinct areas in core for use 
as buffers for incoming data. Each buffer area would have a separate 
storage key specified by the supervisor program. The actual keys to 
be used by the supervisor could be controlled as closely as desired. 

A standard set could be used which are always loaded along with the 
supervisor program. Alternatively, these keys could be entered 
by a designated authority at a supervisory terminal on the system 
console whenever it is desired to alter the key arrangement. The 
necessary procedure for entering these keys can be made sufficiently 
complex, requiring the interchange of various recognition signals in 
a prescribed order, that no possibility of subverting the key structure 
can be imagined. 

When data appears at a data terminal, the I/O control portion 
of the supervisor will service the I/O interruption. It will then store 
the data in the area reserved for that data group, using the proper key. 

When a task program is scheduled to operate on the data group, 
the supervisor will establish a residence area for the program which 
will have a key identical to that of its data group, establish a PSW for 
the task program which specifies the proper key, and establish that 
the task program will operate in the problem state. The task program 
will then be initiated. 
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Output of data through the communication links would be essentially 
a reversal of the above procedure. Data would be assembled in a keyed 
area by the task program. The task program would request that the 
supervisor program perform the output operation. The supervisor 
would then initiate the output via a specified communication line, and 
restrict the output to the area under the key protecting the data group 
to be transmitted. 

Should the task program legitimately require access to data other 
than that under their key, they can request that their key be changed 
by the supervisor. This would, of course, require that the request 
contain sufficient recognition signals to validate the need-to-know, 
or that the supervisor be programmed to honor these requests, knowing 
in advance of the data requirements of each task program. 

The system can be constructed to permit as much security as 
required when responding to requests for access to data or operation 
of programs from terminal device s. Recognition sequences is one 
technique which is feasible and readily amenable to periodic variation 
to enhance security. Also, the operation of terminal devices can be 
under physical lock and key. 

This brief discussion of a hypothetical operating procedure could 
not answer all detailed questions on each facet of assuring security of 
information. It should be clear, however, that there are manifold 
possibilities for various security techniques which can permit the 
uncompromised use of classified data in a multiprocessing environment. 
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ADDITIONAL CONSIDERATIONS 

The system shown in Figure 1 has the capability for providing 
considerable additional protection should it be warranted. There has 
been implemented on some IBM systems a technique known as config¬ 
uration control which will permit electronic partitioning of the system 
and isolation of the subsystems thus created. 

In the essentially duplex arrangement shown in Figure 1, this 
configuration control will permit a very flexible partitioning of the 
equipment into various structures. Some of the possibilities are: 

1. Completely isolated "simplex" systems. This partitioning 
would result in two separate computer systems, each containing 
one of each type of element shown. If it was felt necessary, 
these can be operated as entirely unrelated computing facilities. 

2. Blocking access to various elements. It would be possible 

to completely inhibit one or both storage elements from being 
accessed by one of the computers or I/O control units. It 
would be possible to assign control of both I/O control units 
to one computer, thereby precluding any I/O operations from 
being initiated by the other. These interface controls are 
designed to be operated primarily by a supervisor program, 
although manual partitioning under physical key control can 
also be done. Aside from providing an additional level of 
security when required, this configuration control mechanism 
offers extremely important advantages for maintenance and 
program testing. 

Effective maintenance on a computing system requires the use of 
diagnostic programs designed to exercise the failing equipment and 
isolate the malfunctions to small equipment areas. In the course 
of this exercise, errors will be stimulated to test the equipment. 

The configuration control technique permits the failing element, along 
with other elements required to run the diagnostic program, to be 
isolated from the remainder of the system, while this repair is being* 
performed. Thus, errors in the failing equipment under repair will 
not be propagated to the remainder of the system. 

When newly written programs are to be installed, it is desirable 
to test them in as realistic an environment as possible, yet not allow 
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them to interfere with the operation of the working system. An isolated 
subsystem could be established with configuration control to allow such 
program testing to be done at slack times. 

The capability afforded by the partitioning mechanism can be 
employed for additional security where it is considered necessary. 

It also enhances the flexibility of the multiprocessing system. As the 
system matures, it may be desirable to add additional modules of 
storage, computers or I/O control. Automatic replacement of failing 
elements with spa.res then becomes possible, thereby greatly extending 
system reliability. 
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BIRD BUFFER TASKS 


A. EQUIPMENT 

1. Develop the following shared memory system: 

360/65 

360/44 

9020 

2. Justify selection of all system equipment and features, especially memory 
size, redundant I/O channels, etc. Include a tradeoff study of 27 00 series, 
2900 series vs. PAIVL for comm, links at 1200 bps and TTY, 40. 3 kbps. 

3. Determine for each type system: 

a) I/O Interference for each I/O channel and/or unit 

b) Availability of hardware diagnostics 

c) Channel arrangement of I/O, priority bn channels, 
status conditions to be recognized, size of word blocks, 
existance of timing problems on shared subchannels and channels. 

e) System reliability and availability. 

4. Develop for inclusion in proposal: 

Description of internal data flow for each machine 
Description of any special features including channel RPQ f s. 

5. Prepare DPOWS and RPQ's which may be required. 

6. Develop input/output voltage level, current and impedance characteristics 
of non-IBM interfacing equipment. 

7. Develop recommendations for system grounding. 

8. Determine applicability of DOD Spec.FS222. 

fs^ 

9. Design interface and data flow for 4-3.01 or other applicable disk and 3600. 
a) From descriptions of Mission Center and MOL-Bethesda inputs 

recommendations for 2250 application, 
b) Determine the number of consoles and control units by area, 
include buffer storage requirements. 
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- 2 - 

Bird Buffer Tasks (continued) 


10. Develop formats for I/O words to and from. non-IBM interfacing 
equipment; i. e . expand from 12 bit interface to 16 or 32 bit interface. 

11. Determine any potential effect of equipment and format chan ms in STC 
on RTS operational procedures, programs and equipment, e. g. S fC-Site 
communication message formats. 

12. Ensure system compatibility with Systems Assurance Provisions. 


B. PROGRAMMING 

1. a. Develop inputs from MOL-Bethesda group for MOL impact on STC. 

b. Verify and describe in greater detail the operation of Mulu-processing 
Executive monitor including its operation at initial load, with task scheduler, 
under various conditions of program error or machine failure. 

c. Determine utility of FAA-Operational Error Analysis Program. 


2. Identify software applicable from standard systems, time-sharing and FAA. 

3. Develop recommendations for tracking, command and telemetry processing 
conditions; i. e. sequence, algorithm, selection, timing, table size, table 
design, etc. 


C. APPLICATIONS DEVELOPMENT 
1. Expand use of 2250 display in: 

a) Commanding 

b) Observing TM data points and trends 

c) Controlling and diagnosing center operation 

d) Overseeing site operations and communications in the pre-pass, pass 
and postpass modes. 
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Bird Buffer Tasks (continued 


2. Show applicability of 360 instructions in processing TM data; analyze 
requirements for special TM instructions, such as those used in WSMR-TDC 
proposal. 

3. Develop use of the STC computers for RTS equipment and software 
configuration controlj^STC diagnostics and checkout, including a diagnostic 
that checks computer interface equipment, then all the way through 
communication paths to sites. 

4. Implementation Plan 

5. Maintenance Plan. 

6. Others to follow. (See attached.amendment) 
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Amendment to Bird Buffer Task 
Assignments 

6. Develop method(s) for maintaining secure data requirements in 

multiprocessing configuration through software control. Examples 
of methods to consider: 

1) data coding and storage/processing allocation under 
EM Control. 

2) Encrypting and decrypting programs for internal CPU 
use. 

3) Computer mode switching to change from a true multi¬ 
processing configuration to a stand alone configuration 
whenever "very sensitive" data handling requirements are 
dictated. 
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SYSTEM/360 IN THE SECURE ENVIRONMENT 


Functional Interface 


User interface with System/360 consoles, the 2250, 2260, 1050, 
2740, 2741, is completely a function of the programming in the host 
CPU. In the use of the fully buffered units, the 2250 and 2260, data 
is displayed from or intered into a buffer, which is read/written by 
the processing unit. The printer-keyboard type units, 1050, 2740 
and 2741, are character buffered by a control unit directly under 
the control of the host processing unit. 


Application Interface 

In the anticipated application of the 2250 to the display function 
at the STC, the console/user interaction is described as follows: 

To initiate a mission support request, the user will request 
service by entering a vehicle number and an individual need- 
to-know identifier (perhaps assigned to each user separately 
or to each MCC as an entity). This request will then be 
honored if the identifier is acknowledged valid; otherwise, 
service would be denied and the details of the request logged 
at the Systems Control Center. (As a precaution, all trans¬ 
actions of this type should be logged in a similar fashion.) 

Because of the interface structure, hardware and software, between 
the console user and the processing unit, it is impossible for the user 
to gain access to secure information without the cooperation of the 
controlling programs. There is the very low probability that a memory 
failure, data transmission failure or data recording/retrieval failure 
might occur singly or in combination without detection by the error 
checking circuits of System/360. Moreover, it would be virtually 
impossible to take advantage of the failure because of its typically 
random characteristics. 


Software Interface 


Modification of the operational programs or their verification tables 
to permit unauthorized access has to be accomplished by patching/ 
changing of the existing code, by manual entry at the system console, 
or by integral design into the operating program. The first two 
methods are controllable through operational security techniques 
such as placing the program residence device as well as the system 
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console under lock and key access, forcing direct monitoring of the 
programming maintenance/change function. The latter approach 
requires in-depth knowledge of the program design and integration 
of dynamic program modification techniques into the software without 
detection, both requiring a collusion from conceptual design through 
acceptance test. However, to be effective, such a technique must be 
instantly cognizant of storage protection assignments. Because the 
protection scheme is dynamic and can be varied in any arbitrary 
manner, it would be difficult, if not impossible, to manipulate code 
which itself is protected. Further, the key area in each processing 
unit, locations 0-4095, could be protected further with lock and key 
control over the storage protect function, making this area virtually 
execute-only storage. 


Data Input and History Recording 

The Input/Output devices of System/360, in this case specifically 
the 2702 Data Communications Control, the 2311 or 2314 Disk Files, 
the 2400 tape drives and the 2250 display units, are extremely 
flexible in that they can input/output from anywhere in storage under 
program control. Two approaches exist which enable secure paths 
to be established between the processing unit and the I/O device. 
First, hardware registers constraining selected units to unique 
storage blocks could be implemented. The initialization of these 
registers could be accomplished by special CPU instructions 
executed under lock and key control. The alternate approach utilizes 
the program and data protection as described in the previous section. 
Input/Output tables tying peripheral devices to storage assignments 
and the I/O supervisor itself could be located in lower memory, which 
is restrained to an execute-only mode. 


Summary 

It appears that total data security is possible with System/360 
subject to the very low probability of undetected hardware failure 
and the always-present possibility of collusion. An extension to 
the standard System/360 write-protection capability along with the 
RPQ read-protection feature appears to be the most effective means 
of control while still retaining full compatibility with all System/360 
processing units. 


$ $ $ 
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This paper delineates the software committed or currently available with the 
9020 system as contracted with the Federal Aviation Agency. This software 
capability is divided into three categories. The Diagnostics and Diagnostic 
Monitors which are delivered under the hardware contract, the Utility Program¬ 
ming System which is delivered under the hardware contract, the Operations 
Supervisor which is delivered under the software contract, and the Operational 
Error Analysis Program, a unique real-time, on-line diagnostic program. It 
appears that the software committed under the hardware contract is readily 
available for use at the STC. Additionally, the software which would be 
applicable and was committed under the software contract to the FAA would 
be available through government channels to the STC. 

The following is a brief description of each cf these pieces of software and 
their current application. The addendum to this document delineates the size 
of each of the pieces of software and the estimated percentage of applicability 
to the Satellite Test Center. 

OFF-LINE DIAGNOSTIC PACKAGE 

The Off-Line Diagnostic Package consists of the system end component 
diagnostics as individual packages integrated under various levels of a 
diagnostic monitor. These diagnostics are an extension of those delivered 
with present stand-alone IBM hardware systems. There are basically five 
levels, under a comprehensive monitor. Diagnostic analysis begins with a 
monitor loaded under the initial program lead condition to test the ability of 
the system to execute basic instructions and extending through the highest 
level diagnostic which fully exercises the 9020 as a multiprocessor system. 
This last monitor was developed in support of the multiprocessor configuration 
and is an extension of the normal diagnostic support offered with IBM systems. 
The unit diagnostics furnished with the diagnostic package consist of three 
levels. Starting at the most basic level, the Fault Locating Tests 
(FLT) test and diagnose the IQOE's, CE's and memories and isolate errors 
or malfunctions to a small number of component circuit cards. The second 
level of diagnostics is the Unit Functional Test Diagnostics which exercise 
each unit to determine if it will perform according to its functional specifi¬ 
cations. The highest level of diagnostic routines furnished is that which tests 
the system as a whole. These are the diagnostics which examine the system 
for the operation of the multiprocessing instructions and exercise interfaces 
between the various elements in the system. 


This level of diagnostic support far the 9020 also includes the ability to 
dynamically exercise the system in a scheduled fashion for extremely long 
periods of activity on all components of the system. This ability, the 
Systems Evaluation Technique, or SEVA, allows for reliability checking and 
acceptance tests. 
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These diagnostics do not include support for disks, displays or other adapters 
in the STC configuration. 

UTILITY PROGRAMMING SYSTEM 


The Utility Programming System includes a monitor and programs for the 
production of application software. In capability, it is analogous to current 
systems such as the IBSYS System on the 7094 or the Operating System on the 
1410 system. The Utility Monitor is a single-job, single-task, batched- 
processing system. It runs on the 9020 using a single compute element, a 
single input/output control element and a minimum of two storage elements for 
compilation. It will run in a single storage element, and if more than two are 
available, it will use this additional capability. The following capabilities 
are included in the Utility Programming System. The JOVIAL Compiler at the 
J-2 level operates under the utility monitor. A Basic Assembly Language 
Translator is provided for machine language programming. Typical utility 
functions including a trap-trace program, a core-dump, file-dump and a loader 
for relocatable code. An editor is provided for the maintenance of the utility 
tape for the addition, correction and deletion of the components of the utility 
system. Other capabilities include a symbolic maintenance program, enabling 
the application programmers to maintain and update Symbolic Programs on 
tape. An application library, usable through either JOVIAL or BAL is provided 
for those common routines such as mathematical functions which are required 
in the application. 

The Utility Programming System, as provided to FAA, is a tape-oriented 
programming system. It appears that for the STC the systems design would 
be desirable to alter it to reside and utilize disks. 

OPERATIONAL SUPERVISOR 


The Operational Supervisor is the real-time monitor required to control the 
application tasks. It is general in nature in that it provides the services 
required for operation and control of the 9020 system. These services include 
the supervision of the interrupts including input/output, supervisor call, 
program exception, external and timer interrupts. The machine check interrupt 
is the primary interface to the Operational Error Analysis Program. Input/Output 
supervision is provided for those devices included in the FAA 9020 systems 
design. The Supervisor is designed to operate most effeciently in the real-time 
environment, expediting the handling of the real-time interfaces such as 
communication lines and displays. 


- more - 
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OPERATIONAL ERROR ANALYSIS PROGRAM 

The Operational Error Analysis Program provides the system with a real-time, 
on-line diagnostic capability. OEAP is initiated via the machine check 
interrupt in the Operational Supervisor, external interrupts from other 
components of the system, or via program interrupts caused by storage 
address errors. The OEAP provides real-time analysis of system failures 
and attempts to pinpoint them to a component within the system. Not only 
is this failure pinpointed, but also the OEAP program will then reconfigure 
the 9020 system around the failure to continue the real-time support mission 
of the system. 
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9020 PROGRAMMING STATUS 


STC 


Proqram 

(No. oflnstr.) 

Applicability 

Available 

Diagnostic Monitor System 

500,000 

100% 

Now 

Utility Programming System 

250,000 

100% 

Now 

Operational Supervisor 

6,500 

95% 

7/66 

Operational Error Analysis Program 14 # 000 

100% 

1/67 
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Function 

Source 

Rate Type-Ch. 

No. 
Instr. 

I/O Inter¬ 
rupts/Sec . 

1/ O-Mern. 
(Ref/Sec) 

Instruct. 
(Ref/Sec 

Data Input 

RTS TLM 

300 B/S 

MPX 


3.0 

300 

1350 


2250 Console 

— 

SEL 


.1 


45 

Data Output 

2314-History 

300 B/S 

SEL 


.1 

75 

45 


2250 Display 
4x4 Groups 
per Mission 

500 B/Grp/S 
2000 B/S 

SEL 


4.0 

500 

1800 


2250 Display 
System Control 

4 Displays 

150 B/S 

SEL 


1.0 

38 

450 

Interrupt Handl. 

IOCP 

Message Servicing 

I/O 

Service 

Input 



300p| 

100(M 

250( 3 > 



2000 

500 

Display Formatting 
and Generation 

Output 



400(M 



10000 

Intermediate 

Processing 

TLM 4 

Console Req 



yso^) 



1500 

History File Gen. 

Output 



500 1 2 3 (4) 



1000 

CE-IOCE Mem. Inter 









CE-CE Mem. Inter 

Multiprocessing Task Ass'mt 

Overhead Sched ., etc. 

(1) from 160 code/2.7 (G. West) 

(2) Average OS/360 & 9020 OS 

(3) G. West 

(4) Estimate 


1000 ^) 2000 


913 20690 

21603 (out of 

400,000) 

5.4% 
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NOTES TO 9020 LOADING CALCULATIONS 

A single 9020 CE-IOCE-SE string has 400,000 memory cycles per second 
available for compute and/or Input/Output activity'. Instruction execution 
will always account for a minimum of one memory cycle/instruction (RR 
class), more commonly two memory cycles/instruction (RX class), and 
occasionally more (SS class). Input/Output will utilize one memory 
cycle/byte transferred via the Multiplex channel and one memory 
cycle/word via a selector channel, plus additional references for data 
chaining and command chaining. 

In the STC application, memory contention between a CE and IOCE in 
support of a single mission appears extremely low with the IOCE averaging 
less than one storage request out of 4,000. The CE averages less than 
one request out of 20. 

Extension of this analysis to a 9020 multiprocessor configuration introduces 
additional loading factors. Overhead execution time will be introduced for 
resource management. Memory conflicts will occur between the multiple 
active elements in the system as a function of the memory mapping of the 
application program. This is tempered in that a single CE retains control 
of all active IOCE's and will be in certain memory areas more frequently 
than others. Such a conflict analysis cannot be empirically derived. 
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January 12, 1966 


TO: W. B. Gibson, J.E.Hamlin, J.J.Selfridge. 

FROM: R.V.Coalson, W.C.Derango, D.A.Fuchs, G.D.West. 

SUBJECT: Trip to Manned Space Center. 


On 7 January, 1966, a trip was made to the NASA Manned Space Center for 
the purpose of obtaining information about the RTCC which might be pertinent 
to the upcoming RFP for the SCF. In attendance were the above MOL Project 
personnel and Tom Humphrey, A1 Pfaff, Dave Behne, John Mueller, John 
Bednarcyk, and Bob Kagy from IBM MSC. Information was sought concerning: 
real time programming, multiprocessing, multiprogramming, conversion to 
System 360, system diagnostics, management information, and telemetry. 

It was believed that Houston would probably be the first area of IBM which 
would be attempting to adapt OS/360 to a truly real-time situation, utilizing 
time-sharing, multiprogramming and multiprocessing. Since scheduled 
switchover to System/360 is scheduled for Fall 1966, system design of a real 
time monitor, etc., was expected to be fairly well defined. Additionally, 
new insights into telemetry processing were hoped for, in that the 7094 
receives only slightly formatted data from the tracking stations via the UNIVAC 
telemetry processing system. 

Briefings and conversations with Tom Humphrey and John Mueller indicated 
that the design of the Executive portion of the new 360 system was still some¬ 
what fluid, and pointed out some problem areas they were currently 
struggling with: a) advantages of a shared memory in a true multiprocessing 
situation; b) use of Fortran or PL1 in producing multiprocessor systems; 
c) use of 2250 as a command/control device; d) programming overhead caused 
by more sophisticated systems. It appears that the first 360 system will be 
"stand alone" and operate conceptually like the 7094. Multiprogramming and 
time sharing will be initially employed, but not multiprocessing; this will 
come later. Complete available documentation on modifications of OS/360 
for Houston, and system design philosophy was obtained and discussed. 

Telemetry processing discussions with Bob Kagy and John Bednarcyk revealed 
that the buffering of TLM data from the ground stations to the control center 
is done by UNIVAC computers and programs, (see Figure 1) These facts, 
coupled with the low telemetry processing rate, basically indicate that the 
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IBM Houston real time telemetry processing technology is not as advanced 
as that of the SCF. Lockheed does near real time processing of telemetry 
from analog recordings on the CDC 3300, which is more analogous to the SCF 
operation. Will Derango initiated a luncheon technical discussion with 
Lockheed concerning this activity on an informal basis. Lockheed personnel 
felt that the CDC 3300 is an ideal real time TLM processor. In the Houston 
operation, CDC has included some specialized "TLM" instructions on the 
3300 hardware. Current CDC proposal efforts are under way by CDC to upgrade 
the hardware to a 3800 or "some kind" of 6000 with a verbally promised 
emulator to process existing 3300 code. 

An interesting note on the Lockheed effort is that LMSC Sunnyvale formerly 
had the data processing contract at Houston and was eliminated, due to NASA 
dissatisfaction. Lockheed Electronics Corporation, in conjunction with CDC, 
won the subsequent competiton and proceeded to transfer most of the technical 
personnel (not management) from LMSC to LEG . 

The software system at NASA-Houston is an indication of the present state-of- 
the-art while the new system design reflects the lessons learned from the present 
support activity. There is a need to increase the efficiency of computer 
utilization in the RTCC by means of advanced programming techniques, such 
as multi-processing. The implications have been explored in design studies 
and a limited degree of multi-processing has been recommended. However, they 
are approaching the matter cautiously as it is realized that multi-processing 
is a gigantic undertaking and is not wholely compatible with the planned 
System 360 software. Documentation was obtained concerning their present 
multi-programming operation system. Much of their OS/360 design experience 
is directly applicable to the SCF. 

The approach to diagnostics at the RTCC differs considerably from what is 
anticipated at SCF, mostly from the difference in operating system require¬ 
ments. Since the MSC is not under continuous operation, many hours may be 
dedicated to system checkout prior to vehicle launch, thereby eliminating much 
of the down time. However, the ground rules seem to be that if a station is 
down, it stays down until someone gets around to correcting the failure. No 
requirements for allowable down time have been defined. 

Diagnostics at the RTCC consist only of standard available routines, plus 
a series of tests to determine Go-NoGo status of various system aspects. 

Fault analysis and correction is done under cognizance of Goddard by an 
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analysis system called CADFISS. This will be investigated shortly. 

A1 Pfaff supplied a complete description of the new Model 75 configuration. 

He and Tom Humphrey also had a few comments about the Model 44 system 
to be proposed - namely, concerning the difficulties involved in programming 
a multi-processing system. 

In a single real-time mission support situation, such as NASA's, the need 
for a detailed scheduling and configuration control program is not of paramount 
consideration. In this respect the SCF differs greatly from NASA and will 
require a unique approach to configuration control and scheduling. However, 
OS/360, with its associated peripheral equipment, lends itself favorably to 
methods for solving these operational requirements. 



D. A. Fuchs. 


cc: MOL Project Personnel, 
MOL Project Notebook. 
DAF: jh 
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FIGURE I: NASA HIGH SPEED TLM FLOW 
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LOS ANGELES AEROSPACE BUILDING 
Manned Orbiting Laboratory Project 

December 30, 1965 


TO: Mr. J. J. Selfridge 

TRIP REPORT TO AFSCF, SUNNYVALE, CALIFORNIA 


Messrs. Mort Needle, Robin Mowlem and myself visited the 
Satellite Control Facility at Sunnyvale on December 22, 1965. 

The purpose of the visit was to secure as much information as 
possible about the present SCF configuration, operations, and 
personnel and to ascertain planned growth commensurate with 
increasing support requirements. 

The following persons were visited: 

Lt.Col. N. Alton, Chief of Operations (ACES) 

Lt. W. Kirsch, Facilities (ACES) 

Major Reed, Chief Multiple Operations 
Lt. Col. McCleary, Chief of Data Analysis 
George Hurlbut, Lockheed - Chief of SSOTC 
Bill Pollard, SSOTC 
Bill Braswell, SSOTC 

Lockheed Mission Support Personnel - MCC 

During conversations with the above personnel, the following 
information was obtained: 

1. The Lockheed Configuration Planning Group (SSOTC) has 
recommended to the Air Force five possible modes of operation 
for the IBM 2250's to be leased. The modes are: 

a. Operation as a printer 

b. Selection of one of several formats using mode a. 

c. Graphic 

d. Remotely operating the Bird Buffer computers 

e. Recall of data for history. 

It is very likely that mode a. will be adopted since the processing 
time of the 160A constrains the amount of processing and/or formatting 
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that can be accomplished in each data cycle. Extensive use of the 
2250 in other than mode a. will cause the loss of data from the 
incoming 1200 baud lines. Although the use of 2250's with 160A 
computers severely restricts the 2250's capabilities, this situation 
strengthens our proposed bid for replacing the 160A's with System/360 
computers. This is especially true since the SCF's requirements for 
display requires the full utilization of 2250 capabilities. 

2. The Bird Buffers are not dedicated to particular missions as we 
thought, rather each Bird Buffer is dedicated to a particular remote 
site. Data from all birds which are supported by a remote site pass 
through the Bird Buffer dedicated to the site. This means that data 
security is not a paramount consideration in the Bird Buffer Subsystem 
(as the system is being used). Lt. Kirsch stated that the only area 
in which data security is assured is in the off-line 3600's; however, 
when the Bird Buffers are supporting one of the very sensitive birds, 
the Bird Buffers can be configured to assure hardware isolation for 
the data. (This unique support configuration is used whenever dic¬ 
tated by the SPO office personnel.) At present, only two such birds 
are so supported. 

3. According to Lockheed, there are three types of data in the 
STC. 


Systems Data (Management status) 

Users; a. Multi OPS 

b. Data Systems Director 

c. Systems Controllers 

Telemetry Data (Dynamic status) 

Users; a. Data Display 

b. Data Analysis 

Orbital Data (Non-realtime) 

User: a. Program Engineer (SPO Office) 

4. When Lt. Kirsch was asked about the present Bird Buffer 
utilization, he replied that only 4 percent of the time are there 
more than four Bird Buffers in operation at one time. He also 
stated that they did not use all of the Bird Buffers to support 
operations because they had line sync problems whenever a Bird 
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Buffer was switched between stations. It is for this reason that the 
Bird Buffers are dedicated to a particular RTS. 

5. The Lockheed personnel were very interested in a multiprocessing 
system for use in the Bird Buffer application. They stated that there 
would be an initial problem with NSA data security requirements. 
However, once NSA was convinced of multiprocessing software 

data protection methods, the operation of the system could be fairly 
" relaxed.” 

6. Major Reed was very interested in the 2250’s capabilities and 
potential for alleviating his scheduling problems. Although the 
2250/160A configuration would not afford the amount of flexibility 
required, he stated that he would be interested in any detail 
presentation we might present on the 2250's without reference to 
CPU restriction; i.e. , 2250/OS 360. 

7. Attached is the data flow in the STC. 







l^TLXAi.& 

R. V. Coalson 


RVC/lr (attachment) 

cc: Messrs. J. E. Hamlin, MOL 

R. Mowlem, Bethesda 
M. Needle, MOL 
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Data Flow in the Satellite Test Center 



Note: The MCC will eventually contain the Program Engineer, Data 

Analysis team. Data Presentation Team and the Test Controller 
for each particular mission. The MGC's will be functionally 
reproduced as support dictates. 
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Date 


From (Dept, Loc) 
Telephone Ext. 


February 10, 1966 
MOL Project 



Subject: CDC Price Change 


Reference: 



To-. Mr. W. B. Gibson 


CDC has just recently announced the following price changes to their 
3800 system: 


3804 Processor and Control 
was $14,000 rental 
now 11,500 " 

3803 Core Storage (32K) 

was $13,000 rental 
now 9,250 " 


$710,000 purchase 
450,000 

$560,000 purchase 
360,000 


The remaining component prices remain unchanged. 


This lowers the 3800 system rental price to $2,250 below an equivalent 
3 600 system. 


Substitution of 3800 processing units for the installed 3600's at the STC 
would result in an estimated savings of $1,750 per system. In addition, 
if the 3804 and 3803 are purchased for the STC, payout, excluding 
maintenance, is achieved in 40 months, while the system is good for 
at least 5 years. 


The current National Comstat shows the following: 


Svstem 

Account 

Status 

3800 

OSN Fleet NUM 

Firm Order 

3800 

Mobil Geophysical 

Doubtful 

3870 

NRL 

Firm Order 

3870 

NASA - Michoud 

Doubtful 

3870 

Navy Post Graduate School 

1! 

3870 

NMCS 

11 


(The 38 70 is the time-sharing version of the 3800) 




Mort Needle 
MBN/lr 

cc: Mr. C 0 B. Brown, 
Mr. R. G* Krause 
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Manned Orbiting Laboratory Project 
LOS ANGELES AEROSPACE BUILDING 

March 25, 1966 IBM CONFIDENTIAL 

TO: Mr. C. B. Brown 

Mr. W. B. Gibson 
Mr. J. E. Hamlin 
Mr. J. J. Selfridge 

9020 VERTICAL GROWTH 

I discussed the subject with Lloyd Cudney, 9020 engineering. A similar 
request has already been investigated for the NAPALM proposal, which is 
a 9020 system for the U. S. Army. 

Conclusions were as follows: 

1. Internal speed is more of a limiting factor than SE speeds. 

2. Speed improvements of either CE or SE are not economically 
feasible, since a different circuit family would be required. 

3. The development effort of substituting 2365's (.75 microsecond) 
with 9020 capability for SE's is estimated at $1 million. 

NAPALM has been informed that there is no vertical growth capability 
on the 9020. 

The idea of hanging a 65 or 75 on one of the SE memory tails and 
treating the SE as bulk core is feasible, but has not been investigated 
as to complexity of interfacing the two different circuit families. 

Summary: 

1. Our proposal should avoid committing us to a specific type of 
vertical growth. 

2. We can commit to growth, since there are the following possibilities: 

a. Shared I/O devices 

b. Channel to Channel 

c. A more powerful CPU on one memory tail 

d. RPQ 9020 capabilities onto shared memory 65's 



T. M. Charbonneau 
TMC/lr 

cc: Mr. Lloyd Cudney, POK 9020 Eng. 
Section 3.3.2 
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April 5, 1966 

MEMORANDUM TO: The File 

SUBJECT: 9020 Software 


Following information was gained from conversation with Ken Kowalke: 
The programming developments for the 9020 consist of the following: 

1. Utility systems. This consists of the utility monitor, JOVIAL 
compiler, basic assembly language, mathematical subroutines, 
loader and librarian/editor. These consist of a total of 
250,000 lines of code and have all been delivered and 
accepted. The JOVIAL compiler is a relatively fast compiler 
and uses 256K bytes of core. It compares favorably with 

the J 2 compiler for the 7090. 

2. Diagnostics consist of the SEVA system which are systems 
diagnostics. In addition, there are functional diagnostics 
for each box. Further, the storage units, computing elements 
and IOCE‘s all have fault location technology micro¬ 
programs. These consist of a total 500,000 lines of code 

or their equivalent and are 99% written and debugged. 

3. The operational programs consist of two portions: 

a. Non-operational which includes the upgrade 
utility monitor, simulator and specialized 
programs. These consist of 50,000 lines of code. 

b. The operational programs, in addition to using the 
above, consist of using the operational monitor 
which was estimated, at the time of proposal, to 
require 65,000 lines of code. 

M/ ?;f V 

W. B. Gibson 

WBG:jb 
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SDD POUGHKEEPSIE 
Dept. B70 - Bldg. 951 
Extension - 57538 

May 25, 1966 


Memorandum to: Mr. J. J. Selfridge 

Subject: Alternate Bird Buffer Configuration 

Reference: Meeting in Poughkeepsie, May 10, 11, 1966 

In regard to the discussion concerning Md 44's as an alternate configuration 
for the Bird Buffer, I would like to sum up the conclusions reached at the 
meeting: 

Assuming high availability, error checking analysis, and automatic partitioning 
as prerequisites for the Bird Buffer, the following reasons for not going with 
the Md 44 should be considered. 

1. Lack of spare board room in Md 44 eliminates any expansion without 
going to a separate box. 

2. Memory and channels are integral part of Md 44 which limits partitioning. 
To separate memory would be expensive for a one-of-a-kind system and 
would increase memory speed to at least 1.5 usee. 

3. Lack of error checking in the Md 44 severely limits its application as a 
Bird Buffer. 

Because of the above disadvantages of the Md 44, I would like to suggest two 
alternate configurations for your consideration. 

1. Three stand-alone Md 50‘s, each having its own storage plus duplexed 
shared LCS. 

2. Three Md 50's with shared storage. 

Either of the above configurations are capable of meeting the presently defined 
Bird Buffer requirements. In fact, if future growth becomes a consideration, 
both of these configurations have a decided advantage over the prime 
candidate, the 9020. 
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Comments concerning acceptance or rejection of the proposed configurations 
would be appreciated. 


D. A. Dossin 


DAD/dml 

cc: Mr. C. B. Brown. Los Angeles 
Mr. J. F. DeRose 
Mr. D. Fuchs. Los Angeles 
Mr. C. R. Harden 
Mr. R. B. Hurley 
Mr. R. B. Talmadge. Los Angeles 
Mr. J. M. Terlato 
Mr. G. West, Los Angeles 
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June 6, 1966 

Advanced Programs, Los Angeles, California 
42 7 


STC Buffer Computer Configuration 

Memorandum of May 25, 1966, from D. Dossin to J.J.Selfridge 

Mr. D. Dossin, Bldg. 951, Dept. B70,Poughkeepsie 


The Model 9 020 is our first choice for the STC buffer computer due to its 
hardware features for multi-processing and reliability, and the soft ware that 
could be furnishedat no cost. However, our proposing tKe”~9020 is dependent 
on obtaining an attractive lease price for the machine. 

In the event the 9 020 price is unfavorable, we feel a configuration based on the 
Model 44 would be more suitable than any other configuration of System/3 60 
computers. Considerable cost savings in programming and documentation 
would result by having similar computers at the control center and the remote 
stations. Furthermore, the Model 44 offers a competitive price/performance ratio 

We have recently received information that the Model 44 is being considered as 
a base for a time-sharing system with many of the features we need for the STC.* 
The time-sharing configuration would offer a two-processor system -with the full 
System/3 60 instruction set, dynamic address translation, seven-bit storage 
protection, separate memory boxes and partitioning capability. It appears :nat 
the Model 44 modifications we had requested are more practical than indicaied 
in our meeting of 10 May. 

A configuration of stand-alone Model 50s with shared LCS must be ruled out as a 
possible configuration, since this does not suit our application. Our design calif 
for all programs to be resident in main storage all the time and there is no 
advantage to LCS over disk for data storage. A configuration of Model 50s with 
shared main storage would suit our application but would not be compatible with; 
the 9 02 0 and 44 rationale stated above. 

In light of the studies involving the 44 time-sharing system, we would like to 
pursue the Model 44 modifications listed at our meeting on the 10th of May . 
which were to have been discussed with the Hursley people. 



G. D. West 

GDW:jh 

cc: C.B.Brown, J.F.DeRose, D.Fuchs, C.R.Harden, R.B.Hurley^ J.J.Self Idge, 
R.B.Talmadge, J.M.Terlato. 


"Forecast assumptions: System/360, Model 44 TS"; SSD Poughkeepsie, 
Department D48, Building 706; 25 April, 1966 . 
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CUSTOMER NAME: 


REGION: 


DISTRICT: 


BRANCH: 


BRANCH . MANAGER: 


ACCOUNT MANAGER: 


D, P. SALESMAN: 


FSD REPRESENTATIVE: 


Satellite Control Facility 
Computing Support 
Space Systems Division 
Inglewood, California 


GSM 


Western 


Los Angeles Westchester 


Skip Hoyt 


Ed Chappeiear 


Bob Fairbanks. 
Bob Xrause 
Bob Oiler 


Johnny Jones. 
Jim Self ridge 
Glen McClure 
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PART II. 3600 COSTS (Although Several I604 r s are yet in system-, 
they are in process of being phased out and replaced; monthly rentals 
were approximately same). 


ITEM 


NO. 


TOTAL 


3604 Processor and Console 1 

3603 Core Storage I 

3606 Data Channel (900 ea. ) . 5 

3623 Mag. Tape Controller 1 

606 Mag. Tape Transport (825 ea. ) 8 

3602 Com. Module 1 

3644 Card Punch Controller 1 

3649 Card Reader Controller 1 

405 Card Reader 1 

415 Card Punch 1 

3659 Line Printer Controller > 1 

501 Line Printer 11 

3691 P-T Reader Punch 1 

3681 Data Channel Converter 1 

3682 Satellite Coupler 1 

3000/7000 Data Channel Adapter (Approx) II 
7631-2 File Control 1 

1301-1 Disk File 1 

7 31 Typewriter (approx,) ’ 1 


13, 000 
10 , 000 
4, 500 
2, 900 
6, 600 
2 , 000 
675 
325 
400 
295 
700 
865 
310 
275 
175 
1 , 000 
835 
2, 100 
45 


Total Single Configuration : 


47,COO 


Configurations in SCF: 5-S'TC; 2-AF 


376, 000 


TOTAL SCF MONTHLY CDC LEASE: 700, 938 
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STC 

MANAGEMENT PROGRAMS 
FOREWORD 


Many times in the past, programs for Computer utilization in scheduling, 
configuration control, and information display have been either too automatic 
(i.e. close to 100% computer control) and thus too complicated and costly to 
be practically or economically feasible, or they have been too manual and thus 
too time consuming and liable to human error to be desirable. 

The optimum approach is computer operated programs which allow manual inter¬ 
action or intervention in those areas where human capability exceed those of 
the computer in practical application. Specifically, decision making should be 
a human task while data massaging, formatting, and display is a logical com¬ 
puter task. 

Normally, human interaction with computers causes excessive waste of computer 
operating time in that the computer is "tied up" and unable to process other 
tasks when a human interruption is enacted to allow decision making. 

This is no longer true with the introduction of 2250's, with separate buffer, and 
multiprocessing (or multiprogramming) with executive monitors and priority, 
task tables. Information necessary for decision making can be displayed via 
the 2250 buffer while the CPU is released for other tasks. An interrupt via 
the 2250 keyboard then places the task back in the CPU on a priority basis 
after the appropriate human decisions have been made. 
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An improved, well delineated interaction, between the human delegated the 
responsibility for a task and the computer which is designed for expediting 
the task, is the design goal for the programs which follow. 

SCHEDULING & IMPLEMENTATION PROGRAM 
(SIP) 

The manual scheduling system now in use at the STC has two inherent problems; 
(1) liability to human error, and (2) extreme time consumption between workable 
schedules. 

The scheduling and implementation program (SIP) is a computerized method of 
scheduling which will accomplish the following: 

* 

a. Automate the establishment of of N-hour schedules showing 
stations, satellite acquisition times, and Program Office support 
requests. 

b. Expedite the resolvement of support conflicts*. 

c. Automate the issuance of final schedules to the appropriate 
Remote Tracking Stations and STC personnel. 

d. Display esoteric information to user personnel in the STC. 

e. Record specified information for history. 

** Support Conflicts: -D'efihk two or more support requests at the same RTS 
for the same time period, or for two time periods too close together in time 
to allow turn around at the RTS. 

**N = the time specified by multioperations. 
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The SIP will be supplied its required input from four sources: the 3600 off¬ 
line computers, multi-operations, the Program Project offices, selected data 
from the configuration control program (described later). 

1. Multi-Operations - will manually input the RTS's by name and 
code representation. Once input,this information will remain in 
permanent storage. 

2. Configuration Control Program - will supply up to date RTS 
support capability. 

3. 3600's - will supply acquisition times of satellites over the 
stations (i.e. rise to set times) for an n-hour time period. 

4. Project Offices - will supply statement of support require¬ 
ments for each satellite over each station. 

Utilizing the above inputs, SIP will generate a schedule for N-hours encom¬ 
passing the entire SCF tracking network supporting all missions. Naturally, 
all of the support requests will be impossible to satisfy, therefore the 2250 
will indicate conflicts utilizing flashing lights, arrows, etc. The 2250 
operator will then call the sites one at a time and the scale will be expanded 
to facilitate analysis of the conflicts. (See Figure 1) After consultation 
with the Project Office personnel involved, the scheduler will input data to 
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the SIP to reflect changes in the support requests and a new workable (no 
conflicts) schedule will be generated. After verification of the new schedule 
by all involved, the 2250 will be keyed and the schedule will be transmitted 
over teletype to the site involved. The schedule will also be stored for 
history and printed on hard copy for mangement information. The remaining 
sites will be scheduled in the same manner. 

CONFIGURATION CONTROL PROGRAM 
(CCOP) 

In order for configuration control to be as automated as possible, configuration 
information must be gathered and displayed through a computer operated system 
sensing medium. In a multiprocessing system, which is under the auspices of 
a control monitor, the monitor can act as the sensing medium for obtaining very 
general information about SCF system configuration (i.e. which sites are 
connected to the computing system and in which mode they are operating). 
However, in order for configuration control to be a truly useful tool of manage¬ 
ment, a more detailed level of configuration information must be obtained 
and continuously updated in "real time" . The best medium for obtaining 
detailed information is the set of diagnostic programs which are operated to 
ascertain STC and RTS support capability. NOTE: At any time, voice 
communication with support elements of the STC system can provide up to 
date information on configuration. This data can be input to CCOP via 2250 
keyboard. 
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The Configuration Control Program (CCP) will sense the results of diagnostics 
and tag "out of tolerance" (i.e. not capable of supporting) conditions and 
down grade a 100% support model to reflect non-supporting elements, and 
display the configuration on the 2250 dedicated to configuration control. In 
many instances out of tolerance conditions, as defined by diagnostics, will 
be overruled by project personnel and will become conditions of concern 
rather than conditions of non-support. Conditions of concern should not be 
reflected in the CCP; therefore, a manual input (via the 2250 keyboard) 
should be generated to reflect project personnel decisions and override the 
diagnostics flags. NOTE: Conditions of concern will be shown in the 
Management Information Program. 

For Programmed configuration control, planned RTS down time can be input to 
the CCOP to reflect planned support configurations for any increment of time 
necessary for good operational control. (Example: Philco plans 1 week 
down time for Hula in order to accomplish scheduled maintenance. This main¬ 
tenance is to commence two weeks from the present date. This date can be 
fed to the CCOP and a support capability can be established for the period 
beginning two weeks from the present date. The support capability data can 
then be fed to the scheduling program for the establishment of a support 
schedule. Any change in the planned maintenance can be quickly reflected 
in the schedule by the changing of a few parameters and the resolvement of 
any consequent support conflicts. 
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Another use of the CCOP would be to tabulate history data for management 
usage. Since the CCOP would utilize all the information which describes 
anomalies or catastrophic failures of the support system, a history file can 
be maintained to reflect chornic or repetitive problem areas. The weak areas 
of the support system, the necessity for altered preventative maintenance 
schedules, etc., can be established simply by keying a call to the tabluated 
history file. This same concept could be extended to cover orbiting systems 
as well. (Example: The repetitive rejection of commands by certain 
satellites could be tabulated for history) 

MANAGEMENT INFORMATION PROGRAM 
(MIP) 

Management information is simply an outline or brief of all data of critical 
nature which is utilized for effective management of an operational support 
system. Management information, is usually gathered after a request has 
been made for information concerning a particular aspect of the system. The 
data requested is then manually collected from recorded date (and conversations 
with support personnel) to reflect the information required. MIP, then, is a 
program which gathers, formats and displays information necessary for 
effective management of the entire support system. 

The following types of information are required for updating the Management 
Information Program: 
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a. Daily support schedules (obtained from SIMP) 

b. Daily equipment configurations and equipment status 
(obtained from CCOP) 

c. Voice Communication with the RTS's. 

The information will be used primarily for two purposes: 

I. SCF management planning for future procurements,technical 
direction to contractors, etc. 

II, System Controller and Data Systems Controller directions 
during missions to assure rapid, well planned and 
orderly assignments for correcting abnormal conditions 
(anomalies, reconfigurations, equipment repairs, etc.) 

1. Since Management planning is based upon statistics of past, present 
and projected future operations, there is a continuous gathering of information 
to substantiate management positions. Technical direction to contractors 
requires operational data to substantiate the requirements levied upon the 
contractors by the Air Force management. The Management Information 
Program will provide the needed data in near real-time in any of various 
formats desired. MIP will not require extensive data processing since it will 
draw the needed information from existing operational programs. The MIP 
display medium (2250 or hard copy) will provide the capability to chose 
formats which best suit the time of inquiry. Most of the information will 
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come from the CCOP. (Note description of CCOP preceding) 

2. Operationally the MIP will be very useful to the System Controller and 
the Data Systems Controller. When unexpected anomalies occur in the STC 
System (includes RTS's), the System Controller can call information sufficient 
to make rapid assessments of the problem area(s) and delegate the respons¬ 
ibility for repair. Since he will know the degree of the problem, he will be 
able to make accurate estimates as to time of repair and the seriousness 
of the difficulty. This is especially important in manned orbital missions 
since ground support during repair missions is of paramount importance. 

The ground support personnel must have enough information to properly 
assess the situation. The MIP will satisfy this requirement. 
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EXAMPLE 

SINGLE SITE RESOLUTION 


CONFLICT - Shows as 
Flashing Symbols 




HULA 

Support Requested by 
Program x Project Office 




o 


Support Requested by 
Program y Project Office. 


nnnnnnnn 


WWWWWWWW 


Support Requested by 
Program z Project Office 



Codes for Satellite Programs 

Example: xxxxx = program x 
ooooo = program y 
zzzzz = program z 


TIME 


NHour Schedule 


Could be Overlays 
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CUSTOMER NAME: National Range Division 

Air Force Systems Commmand 
Washington, D. C. 


REGION: GEM 


PROGRAM: Air Force Programs 


PROGRAM DIRECTOR: • Ray Simms 


PROGRAM MANAGER: Jack Richardson 


SPECIAL REPRESENTATIVE: Bob Bruns 


SYSTEMS ENGINEER: Michael Bibault 


FSD REPRESENTATIVE: Ken Driessen 
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HQ NRD OFFICE SYMBOLS 
PATRICK AFB 


11 J hm 1965 


NRG COMMANDER Gen. Davis 

NRGV Vice Commander Col. Gibson 

NRGC Executive Lt. Col. Leammonth 

NRGS Chief Scientist Dr. Hess 

Asst. Chief Scientist Lt. Col. Lake 
NRA OFFICE OF ADMIN SERVICES 


NRC 

NRCM 

NRCR 


NRO 

NROA 

NROC 

NROE 

NRP 

NRPR 

NRPP 

NRPPA 

NRPPR 

NRPPS 

NRS 

NRSC 

NRSCI 

NRSCP 

NRSI 

NRS1D 

NRSIS 

NRSM 

NRSP 


PROGRAM CONTROL OFFICE 
Program Management Division 
Resource Management Division 


Mr• Lachar 
Lt. Col. O'Brien 


INTERNATIONAL AFFAIRS AND SPECIAL PROJECTS OFFICE 


DIRECTORATE OF OPERATIONS MANAGEMENT 

Operations Analysis Office (open) 

Range Control Division Lt. Col. Ligon 

Operations Evaluation Division Lt. Col. SchOU 

DIRECTORATE OF PLANS AND REQUIREMENTS 

Requirements Division Lt. Col. Lineberger 


Plans Division 


Col Volcek Perhacs 


Col. Butler (open) 


Col. Pellegrini 
Dr. Fennema 


Advanced Plans Branch Lt. Col. De Lisle J 
Resource Plans Branch Lt. Col. Weingand 
Systems Plans Branch Lt. Col. CuramingS 

DIRECTORATE OF RANGE DEVELOPMENT Col. Eving * 


Communications Division 
Network Implementation Branch 
Network Planning Branch 
Instrumentation Division 
Data instrumentation Branch 
Support Instrumentation Branch 
Mobile Stations Division 
Air Force Representative. ISPO 


Mr. Jones 
Mr. De Russo 
Mr. Nordbusch 
Col. Heraans 
Maj. Haberman 
Maj. Brashears 
Lt. Col. (open) 


WESTERN PLANNING OFFICE (Los Angles AF Station) 

Col. Anderson 

PERSONNEL 


DDMS 


DOD MANNED SPACE FLIGHT SUPPORT OFFICE 


Col. Olson 


MaJ. Magrane 


DEPUTY COMMANDER AFSC FOR GLOBAL RANGE (Andrews AFB, Wash) 

SCGR DEPUTY COMMANDER 
SCGRP Directorate of Plans and Operations 

SCGRS Directorate of Range Development 
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r~PMT- 

SHEET 

BIOGRAPHY 

of 


orrtce or information 

NATIONAL RANGE DIVISION, D*r. 1 


mthick Am force base. Florida 

TELEPHONE COCOA MCACN, rLA. 4M-77J1 



LIEUTENANT GENERAL LEIGHTON (LEE) IRA DAVIS 




General Davie conanands the National Range Divisioh(NRD) and is Department 
of Defense Manager for Manned Space Flight Support Operations. 

Bom in Sparta, Wisconsin, February 20, 1910 f 

Entered United States Military Academy in 1931, graduated 1935* . Also 
holds Masters Degree in Aeronautical Engineering from Massachusetts Institute 
of Technology (1941) and is a graduate of Air War College (1950). 

Received pilot rating 1936, now holds Command Pilot rating. 

Assignments bear out reputation as soldier-scientist. Instructor, Depart¬ 
ment of Mechanics, West Point (1939-1942); Ground School Director, West Point 
(1942-43); Project Officer Technical Executive, Chief, Armament Laboratory 
.(1943-47); Assistant Chief, Engineering Plans Brsfach, Engineering Division 
(1947-48), Chief, Applied Research Section, Air Materiel Command (1948-49), 

Chief, OFC Air Research, AMC (1949) - All at Wright-Patterson AFB (1950-51); 
Deputy Commander and Commander, USAFIT, Wright-Patterson AFB (1950-51); 

Director of Armament, ARDC (1951-52); Assistant Director and Director of Develop¬ 
ment, ARDC, (1952-54); Commander, Air Force Missile Development Center, 

Holloman AFB, N. M. (1954-58); Deputy Commander for Research and Development, 

ARDC (1958-59); Assistant Deputy Chief'of Staff, Development, Headquarters 
U$AF (1959) J Conmander, AFMTO, Patrick AFB, Florida (May I960). 

-more- 
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General D&vis is married to the former Gertrude Austin of Lyndhurst, N. J* 
Three children, Mrs. Robert M. Brown, Mrs. James C. Faris, and son, Leighton 
I. Davis, Jr. 

Received Legion of Merit for development of electronic pressure-time, 
pressure volume equipment used at West Point, Oak Leaf Cluster of Legion 
of Merit for design and development of gun-bomb-rocket sights for fighter 
aircraft. Received Thurman H. Bane Award from Institute of Aeronautical 
Sciences for work in developing fire control equipment and Honorary LLB, 
from the New Mexico State University. On May 21, 1963, the late President 
Kennedy presented General Davis with the National Aeronautics and Space 
Administration’s Medal for Outstanding Leadership in recognition of his 
contribution to Project Mercury. 

For recreation likes golf (shoots in low eighties), bridge, enjoys hi-fi, 
fond of hunting and fishing. Has extensive collection of electronic devices 
which he constructed, and war game which he patented. 

Is Fellow of American Rocket Society, member of Order of Daedalians. 

General Davis assumed command of the National Range Division on 2 January 
1964# and was promoted to Lieutenant General on 1 June 1964• 

-AVRTR- 
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CUSTOMER NAME: Western Test Range, 

Vandenberg Air Force Base, 
California. 


REGION: 


DISTRICT: 


BRANCH: 


BRANCH MANAGER: 


ACCOUNT MANAGER: 


DP SALESMAN: 


SYSTEMS ENGINEER: 


FSD REPRESENTATIVE: 


GEM 


Western 


Los Angeles, Westchester. 


Skip Hoyt 


Paul DePascal 


Jay Priday 


Dick Stanley 


Paul Lindfors, 
Johnny Jones, 
Jim Hamlin. 
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Western Test Range 
Vandenberg AFB, Calif. 



Col. Clark Requirements 



O 

O 

3 

a 

D 

m 

S3 


4.1 


Air Force 


Lt.Col. R.F. O'Neil - Personnel 
Lt.Col. L.W. Fry - Materiel 
Lt.Col. H.L. Stillens - Comptroller 
Maj. L. R. Gill - Administration 


Range Support 
Col. Delaney 


IBM ' 

Paul O. Lindfors 
John Jones 
Jay Priday 
Diek Stanley 
Paul DePascale 
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Engineering 

Col. Hoffman- - - - - Technical Advisor 

Bill McGraw 


Air Force 


IBM 


Lt.Col. J. M. Ellzey - Ships 
Lt. Col. P. Andrae - Proj. Control 
O')Mr. W. Cuthbert - Instr. Engr. 

Q} Mr. B. Ames - Comm. Engr. 

£/>Mr. C. Cusworth - Comp. Engr. 

Col. C. H. Andrews - Facilities Engr. 

/2)Mr. Bob Effenberger 
C& Mr. Jim Allison 
(2) Mr. Chuck LeRoy 
CS) Mr. Ted Barr 

Maj. Glen Ballantyne - MOL Range Support- Special Assignment 

Mr. Lou Kraff - Director Systems Engineering 

Mr. Bert Larey - Systems Engineer 

Mr. Chesebro - Communications Engineer 

Mr. Criddle 

(4) Mr. &inglle - Command & Control 


Paul O. Lindfors 
John Jones 
Jay Priday 
Dick Stanley 
Paul DePascale 


(number) - Denotes chain of Command 
under particular section 
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Operations 
Col. Vinzant 


Air Force 


• IBM 


(ri Mr. Alexander - Range Data 
/JT. Col. Montalvo - Range Ops. 

Lt.Col. R.B. Moody - Range Safety 
Col. Hill - Chief Scientist for Range 

Operations 


('-?) Mr. McDowell ) 
C3> Mr. Cristophono ) 


Math. Analysis Ap. 


Paul O. Lindfors 
John Jones 
Jay Priday 
Dick Stanley 
Paul DePascale 
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Procurement 
Col. Clark 


Air Force ___ 

Lt.Col. R. F. O’Neil 
Mr. W. T. Heavner 
Mr. K. Ito 
Mr. D. Templeman 



IBM 

Paul O. Lindfors 
John Jones 
Jay Priday 
Dick Stanley 
Paul DePascale 
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Plans and Requirements - - - 


Air Force _ 

Col. Carey - Advanced Plans 
Mr. Bradford 

Lt. Colonel Chuck Fellows - Director, Advanced Programs 


O 


- Colonel Godfrey 
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Technical Director to Commander - - - - Mr. S. D. Radom 


Air Force 

Mr. Gene Clarey - Chief of Operations Analysis 
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C. CURRENT STATUS 

C.l A Technical Report entitled "Consolidated Range Control 

Center" was completed and delivered to WTR December 15. 
The introduction to the report follows. Further information 
concerning this report can be obtained through the MOL 
Project Office. 
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1.0 INTRODUCTION 


1 - 1 SCOPE OF THE REPORT 

The present growth potential of the Air Force Western Test Range dictates 
the consideration of a Consolidated Range Control Center to meet AFWTR 
functional requirements and allow for modular expansion of both the hard¬ 
ware and programming systems. This technical report presents the IBM 
preliminary system design for the CRCC at AFWTR. 

The contents of the report are ordered to allow both quick assessment of 
the composite system and detailed perusal of its individual elements. An 
abstract of its subject sequence follows: 


Section 1 Design Considerations 

A summary of considerations which influenced the 
design of the system. 


Section 2 General System Design 

A condensed identification and description of the 
computing system which IBM has designed for CRCC. 
Includes graphic summaries of hardware and software sub¬ 
systems and range functions which the system supports. 


Section 3 Detailed System Descriptions 

Detailed technical discussion of the CRCC computer 
configuration, the telemetry receiving complex, the 
communication system, computer application and system 
programming, the management information system, and 
the range safety function is discussed. 


Section 4 Facilities 

Description of facility considerations which result from de¬ 
sign of the data system. 

This data system design for the CRCC has been based upon IBM's present 
understanding of AFWTR functional requirements. To this extent, the 
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system should be regarded as preliminary since numerous contingencies 
can modify support requirements as the range grows. 

IBM will welcome the range's response to this design approach and is 
prepared to modify and adapt as the system contingencies arise in 
AFWTR's expanding user support mission. 

1 .2 DESIGN CONSIDERATIONS 

In considering the various aspects of a consolidated approach, it becomes 
apparent that the computing function provides the single element common 
to most system users. It is, however, quite clear that the computing 
elements of this system cannot be specified in an abstract fashion. It is 
convenient to consider the computing system as a node point in the flow of 
raw and processed data at AFWTR. The design of the data processing 
system must reflect a capability to accommodate the network of data flow 
paths as envisioned during and after the consolidation. The key factors 
to consider are the number of data paths arriving at or emanating from the 
computing complex and the maximum expected over-all data flow rate. 

Closely allied with the requirement to receive and transmit data is the 
amount and type of processing (arithmetic, converting, routing, etc.) re¬ 
quired to be done on this transient data in real time. These real time 
requirements are dictated by range operational functions such as the pre¬ 
diction of impact, orbit determination, quick look experiment analysis, and 
other rapid turn-around tasks. The need to perform a variety of real time 
processing while at the same time managing the flow of data will determine 
the characteristics of the central processing element and govern the 
selection of I/O devices associated with the central processor. 

Once a given central processing element has been defined it is necessary 
to address the total processing system for the sake of achieving a configura¬ 
tion which will provide for maximum sustained support to on-line operations 
should a failure situation occur. This historically has been solved through 
the application of redundant elements in the system. The determining factor 
in establishing maximum protection against interrupt or cancelled support 
is the amount of time allowed to transfer critical functions from a marginal 
device to one that is functioning correctly. By employing appropriate 
switching equipment and pooling equipment, the required recovery capability 
can be achieved without resorting to 100% hardware duplication. 

In designing a consolidated center it is also necessary to inspect the off¬ 
line or non-real time demands on the processing system. In this case, the 
two factors of the operating system and the I/O configuration are the 
determining ones. This is based on the assumption that the central 
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processing element has been sized to accommodate the real time or mission 
support requirements. 

The foregoing considerations can be divided into two broad categories: 

1. Those pertinent to on-line real time mission 
support 

2. Those relating to off-line operations. 

Ideally, then, an equipment system should be developed which can simply 
and rapidly be reconfigured .to meet specific applications. 

In the remainder of this report, an attempt has been made to interrelate 
these considerations. To achieve this, the report explores the following 
areas: 


1 . Communications Network - including data rates 
and routes. 

2. Telemetry Processing 

3. Software System 

4. System Applications 

5. Facilities 
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C.2 The current status of the range plans and work loads are 
summed up in the reproduced MISSILES AND ROCKETS 
article attached. 
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Vandenberg Begins Expanding for MOL 


Acquisition of huge ranch adjoining space base will be first 
step toward meeting needs of continuous launching; new Titans planned 

by Robert Lindsey 


Vandenberg Air Force Base, 
Calif. —The U.S. Army Corps of En¬ 
gineers has been negotiating to acquire 
the 14,891-acre Sudden Ranch proper¬ 
ties adjacent to this base as the first step 
in a massive expansion program trig¬ 
gered by the Manned Orbiting Labora¬ 
tory (MOL) program. 

Brig. Gen. Joseph S. Bleymaier, 
commander of the Western Test Range, 
told Missiles and Rockets he sees “a 
real good possibility” that within five 
years Vandenberg will have “continuous 
manned operations,” involving perhaps 
as many as 40 or more launches a year. 

Meanwhile, M/R learned that last 
summer’s Titan III-X studies have ma¬ 
tured into firm designs for two new Air 
Force launch vehicles that will be used 
to orbit advanced unmanned reconnais¬ 
sance satellites and other military pay- 
loads from Vandenberg. They include: 

—Titan Ill-B. This will consist of 
the first two stages of the Titan III-A, 
less the malfunction detection system 
and other man-rating equipment, plus 
an upper stage. Initially at least, it will 
be used only with an Agena upper stage. 
The Titan 11I-B will be radio-guided and 
be capable of orbiting payloads of about 
8,000 lbs. 

—Titan III-D. This will consist of 
the Titan IH-B, Agena or other upper 
stage, plus two two-segment, 120-in.- 
dia. solid motor strap-ons. Payload will 
be about 50% greater than that of the 
Titan Ill-B, or approximately 12,000 
lbs. A three-segment strap-on motor de¬ 
sign is still under consideration. 

In still another version of the Titan 
111, use of seven-segment 120-in. motors 
(instead of the five-segment motofS used 
in Titan III-C) apparently has been 
firmed up for the MOL launches from 
Vandenberg. For a time at least, Air 
Force sources said, 156-in. motors have 
been ruled out of the MOL program. 

United Technology Center of Sunny¬ 
vale, Calif., is now working on a Pro¬ 
gram Definition Phase (PDP) contract 
for the seven-segment motor. Informed 
sources say the firm will get a develop- 
tuent contract early this year. 

The seven-segment motor probably 
would produce about 1.5 million lbs. of 

missiles and rockets, January 10, 1966 


thrust, compared with 1.2 million lbs. be dubbed Titan III-E. 

of the Titan III-C motor. Designation Unmanned activity—While this 
of the Titan III employing seven-seg- Strategic Air Command base is being 
ment motors hasn’t been determined as readied for what promises to be a fast- 
yet, although one source said it would paced program of manned space oper- 




Map shows how purchase of 14,891-acre Sudden Ranch (light area) south of existing 
space facilities will add substantially to both ground area and coastline. 
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ations. Hie tempo is also rising in the un¬ 
manned military space activities. 

Modification o!' a former Atlax- 
Agena launch complex to handle the 
Titan IIl-B is now well under way and 
is scheduled to be completed late this 
year (M/R, Dec. 20, p. 9). 

Although payloads assigned to the 
Titan HI-B arc classified, it is be¬ 
lieved that the primary one is a larger 
version of the SAMOS reconnaissance 
satellite. SAMOS is now launched by an 
Atlas-Agena with a payload capability 
of about 7,000 lbs. Apart from its pay- 
load increase, Titan III-B would give 
this program the flexibility and quick 
response possible with storable propel- 
! lants, not available with the Atlas- 
Agena. Larger payloads resulting from 
use of lll-B and Ill-D would permit sev¬ 
eral reconnaissance refinements, includ¬ 
ing multiple film recovery capsules. 

Early MOL qualification flights will 
be conducted from Cape Kennedy, but 
all manned MOL missions will be flown 
out of Vandenbcrg, to take advantage 
of the facility’s capability to launch pay- 
loads into polar orbits. 

$53 million in construction—Bley- 
maier estimates construction of the 
initial launch capability (ILC) com¬ 
plex for the MOL will take about 30 
months.' ! Hence, the launch complex 
should be ready for the first manned 
MOL flight in late 1968. Bleymaier said 
he expects work on the Sudden Ranch 
to hit full swing in about March. Esti¬ 
mated cost of ILC, an “all-purpose” 

! facility that will also handle Titan Ill-D , 

| is $28 million. 

The single launch pad of the ILC 
will, in effect, be the core of the Titan 
III Integrate-Transfer-Launch (ITL) 
complex at Cape Kennedy. Ultimately, 
Bleymaier said, construction of an en¬ 
tire ITL here is inevitable. But he said 
the decision probably won’t be made for 


“another couple of years.” This points 
to the ITL becoming operational in 
about 1969 or 1970. Estimated cost 
of completing the TI L is about $25 mil¬ 
lion, in addition to the 1L.C costs, 
Bleymaier said. 

Although there has been support for 
establishing the MOL mission control 
center at Vandenbcrg or at the Air 
Force Space Systems Division head¬ 
quarters at El Segundo, Calif., sources 
said there have been no changes in early 
plans to give the mission to the Air 
Force Satellite Test Center at Sunny¬ 
vale (M/R, Nov. 22, p. 16). 

“Time of Transition”—Bleymaier, 
the main driving force behind the highly 
successful Titan 111 program and a 
leader in early MOL planning, con¬ 
ceded that he’s now seeing space opera¬ 
tions from a new light. 

“For years,” he said with a grin, “I 
was able to lay down requirements on 
the ranges. Now I’m finding that having 
to satisfy the requirements laid down by 
others can be a real challenge.” 

This is a “time of transition” for the 
Western Test Range, he observed. Until 
now, he said, space operations here have 
been conducted from converted ballistic 
missile launch pads. 

“Now for the first time we are build¬ 
ing facilities for space from the ground 
up,” giving the Air Force opportunities 
to optimize facilities to fit its needs more 
precisely. 

Bleymaier said the WTR will re¬ 
quire only “moderate” augmentation 
to handle manned flights, essentially 
addition of biomedical monitoring facili¬ 
ties along the range. 

He noted that extensive space medi¬ 
cine facilities are being included in a 
new 125-bed base hospital now under 
construction—another sign that Van- 
denberg is going into the manned space- 
flight business. El 


AF Orders New Long Tank Thors' 


LONG TANK THOR, a new 
version of the Douglas Thor space 
booster offering greater payload 
capability, will be used for the first 
time this summer, the Air Force has 
announced. 

Approximately 70 ft. long, com¬ 
pared with 56 ft. for previous 
models, the new vehicle is essentially 
a Thrust-Augmented Thor (TAT) 
with a longer tank and upgraded 
solid-propellant strap-ons. The three 
strap-ons are off-the-shelf Castor II 
solid motors which add a total of 
18,000 lbs. of thrust more than the 
Castor I motors used on the TAT. 
Thrust of a single Castor II is 70,450 
lbs., compared with 64,530 for 
Castor I. . 


Air Force Space Systems Divi¬ 
sion has ordered 22 of the new ve¬ 
hicles from Douglas Missile and 
Space Systems Div., Santa Monica, 
Calif., at an estimated cost of $18 
million. These are all production 
models, not modified older versions, 
and the Air Force expects to utilize 
them quickly and order further pro¬ 
duction. In the usual process of 
standardization, it says, the new 
Thor eventually would replace all 
older versions for Air Force and 
NASA missions. 

Thrust of the main engine re¬ 
mains at 170,000 lbs. Total thrust 
of the Long Tank Thor is 348,000 
lbs. Increased payload capability is 
achieved with longer burn time. 


missiles and rockets, January 10, 1966 
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PROGRAM AND OPERATION CONTRACT 


Federal Electric, who currently has this contract, has 
indicated that this will be up for RFP again on or about February 15, 
1966. This covers both the programming and operation of the WTR 
Range Safety and Data Reduction Facilities. 
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November 15, 1965 

MEMO TO THE FILE 

SUBJECT: November 12 Call on Col. Carey 


On November 12, Jay Friday, Dick Stanley and Bill Gibson called on 
Col. Carey to follow up on our Wednesday presentation. Purpose of the 
call was to confirm that we plan to be on the base Monday and for the 
following month, with a target of producing a solid and detailed design 
for Col. Carey within one month’s time. He confirmed that this would 
be timely and talked for almost an hour covering the following subjects: 

1. The new Headquarters area will be at Thirteenth and California 
right adjacent to the new building the Wing is putting up. He 
stated that Headquarters is moving in right next to the Wing 
deliberately. 

2. The Wing which is proposing the TMCC, avoided talking to 
Headquarters until very late. When they started talking, 
Headquarters enthusiastically joined and endorsed their efforts. 
The TMCC had a computer size for real time to ” shred out and 
display” data for the Wing. However, it had no idea of encompas¬ 
sing all the other WTR functions. Col. Carey states that "We 
propose to go all the way. ” We will take their computer room and 
gain control of their operation. 

3. He stated we will reorient a communications net to come into 
these two new buildings. 

4. We will expand the Wing activity until it’s big enough to serve our 
needs, and we will run the Wing down in the process. 

5. There will be an organizational restructuring of the Air Force 
Systems Command on Vandenberg soon. 

6. A Division commanders meeting will be held at Vandenberg 
within two weeks with Shriever, Funk, General Light and Davis, 
the other Davis and Houston attending. The main purpose of this 
meeting will be a discussion of the Air Force Systems Command 
effort and the feeling that Shriever will reorient WTR to obtain 
more harmonious working relationships. 

- more - 
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7. Therefore, Col. Carey says the Consolidated Range Control 
Center makes even more sense. 

8. Col. Carey stated the following rules for a new center: 

a. It cannot be a "pods” operation like ETR which IBM 
did on RCA equipment. 

b. The executive director program must use standard 

Air Force supply programs such as "AFUND, " "RAIS. " 

c. In regard to RAIS, Col. Carey stated that he felt the 
Air Force Information Retrieval system developed for 
SAC was a better program. 

d. The system developed must have multiple accesses of 
data with the remote terminals in and out. 

e. The Range Safety system must have appropriate safe¬ 
guards. 

f. Range safety should be split into two inputs with 
real-time data which can be destroyed going into the data 
reduction function and other data generating an audit trail 
for Range safety. Range safety items must be locked 
under the control of the Range Safety Officer. 

9. Col. Carey stated that everything would be coming in via micro- 
wave if not on standard communication facilities. Jay Friday 
brought up the point that the CTCS seems to duplicate some of the 
equipment in the TMCC. Col. Carey stated that this was because 
he was unable to get complete control of it and that the CTCS has 
equipment which is common to all users. That the Range is 
responsible for supplying the equipment, but the user is responsible 
for what the data says. 

10. The Wing in planning for the TMCC duplicated some of the CTCS 
equipment. 

11. Our proposed CRCC must handle CTCS function. 

12. A key target date is the 15th of December when a draft of the 
Range package plan must be done and ready for headquarters 
review. The final plan must be ready by January 15. Therefore, 
Col. Carey stated that our target of having a report in within a 
month is timely. In reference to previous discussion, the 15th of 
November formally was supposed to be the date at which the first 
draft of their Range Package Plan was prepared. 

- more - 
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13. We discussed with Col. Carey that we saw the main action required 
on our part to be in the data reduction, range safety, telemetry, 
management information system and communications control. He 
agreed that these covered the major areas. He stated that any 
attempt to do program control switching of communications 
equipment would give the communications people a fit, but told us to 
go ahead and try. He suggested that we use Major Conelly on his 
staff as assistance in entering the management information area 
and also if we ran into difficulty in the.telemetry area. 

14. We discussed the possible difficulty of securing information in the 
telemetry area and he said if it got too serious to see him and he 
would attempt to assist us. In discussing how we found out what 
the Range future requirements would be, he stated the following: 

a. . In the immediate future STLS would be the highest 

performance equipment we would have to consider. 

b. They were planning on using their own military 
instrumentation satellite to handle communications up 
from the Range and, therefore, any system planned must 
plan on higher speed communication in the future. 

15. In concluding and as we were leaving, Col. Carey stated "there is 
a great deal to be done. NRD Headquarters is not sensitive and 
doesn’t recognize the problem. I need help there." 

I would conclude that this is a very successful call and that we absolutely 
must have our systems design in two to three or four days prior to 
January 15 at the latest. Revisions to our plan are possible after this date 
but it will make it harder to be included in the Range Package Plan. 

Please call me on any points of discussion or interest regarding the above. 


W. B. Gibson 
WBG:jb 

distribution: J. E. Hamlin 

C. B. Brown 
J. Priday 

D. Stanley 

P. DePascale 
R. P. Bruns 
H. G. Hoyt 
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October 18, 1965 


To: Mr. J. E. Hamlin 

Subject: Trip Report - Telemetry Processing Center at WTR 


On Oct. 13th I visited the Western Test Range at Vandenberg AFB. The 
following observations were made during various meetings held on this date. 

1. Instrumentation Section of Range Engineering 

a. Mr. Jim Allison intends to submit a work statement to Pro¬ 
curement for a Telemetry Processing Center. He is apparently 
writing this work statement without input from the Computer Systems 
or Operations branches of his parent organization (see attachment). 

It is planned that this work statement will be in Procurement by 
Nov. 15th, with an operational system date in early 1967. 

b. Mr. Allison indicated that he is looking at two approaches 
in writing the system specifications and configuration. (From later 
conversations with Mr. Fred Barr of Computer Systems, it seems 
that Beckman presents one of these approaches and is probably the 
influencing contractor.) 

c. Mr. Allison indicated that he is interested in the long 
range approach, i.e., an integrated control facility, but he is not 
particularly biased toward an integrated facility in terms of equip¬ 
ment location in one centralized building. 

d. The building to house this proposed center has been approved 
for construction. It will consist of a 9,000 sq. ft. annex to the 
existing CTOS building and will cost approximately $500K. 

2 . Data Section of Range Operations . 

a. Mr. Jim Alexander repudiated the engineering plans for a 
Telemetry Center.. He stated that he was not intimately familiar 
with the work statement and further stated that he "didn't really 
care" (sic) since he had not submitted requirements for additional 
* or new systems to Engineering. Mr. Alexander stated that Jim 
Allison's unilateral action violates the normal mode of range opera¬ 
tions, i.e., engineering design based upon requirements levied by 
Operations. 
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Mr. J. E. Hamlin -2- October 18, 1965 


3. Systems Section of Range Engineering 

a. Mr. Ted Barr stated that his organization had not furnished 
inputs to the Telemetry Center work statement. He believes that 
this work statement will be proscribed by management on the grounds 
that there is no input from his organization. 

From the above described meetings it seems apparent that Mr. Allison’s plans 
for a Nov. 15th procurement will be vitiated due to lack of technical approval 
at higher levels (probably Mr. Stan Radom). The work statement will un¬ 
doubtedly be rewritten with all appropriate organizations contributing inputs. 

Rather than try to conform to Mr. Allison's present concept of the Telemetry 
Center, IBM should concentrate on the organizations most likely to influence 
the final procurement. Conversations with Mr. Barr and Mr. Alexander in¬ 
dicate are not inexorable in their ideas about an integrated facility to satisfy 
telemetry processing requirements. In fact, Mr. Barr seemed well pleased 
with the IBM approach as presented very briefly by Jay Priday and myself. 



R. V. Coalson 


RVC/jeb 

Attachment 
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Attachment to Mr. R. V. Coalson's Trip Report of October 18, 1965 to 
Mr. J. E. Hamlin 


The persons referred to in this memo are shown organizationally below. 


WTR 

Gen. Bjeymaier 

Stan Radom - Tech. Dir. 


--j- 

1 

Engineering Operations 

Col. Hoffman Col. Vinzant 


( 


xrstrum e ntation 
Cuthbert 


Systems 

Cusworth 


Data 

Jim Alexander 


jim Allison 


Chuck LeRoy) 
Ted Barr ) 


Computer 
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November 11, 1965 


RESUME 1 OF BRIEFING GIVEN GENERAL BLEYMAIER AND WTR STAFF 

November 10, 1965 at 2:00 p. m. 


Summary: 

Customer expressed disappointment that we did not present a detailed 
design idea. He felt our presentation was too filled with generalities and 
motherhood. Specifically, our recommendation of a short study prior to 
going out to RFP was unacceptable. This was interpreted as meaning that 
the customer wants immediate help from IBM in generating a design that 
they can use as a basis for an RFP in the near future. Attached are debrief' 
ing comments from the individuals who attended from IBM. 


Action: 


Since the Range is on vacation November 11, we will return Friday, the 
12th, to start immediate action aimed at coming up with a detailed systems 
design within three weeks. 


Distribution: C. B. Brown - MOL Project 

R. P. Bruns - MOL Project, FRO (GEM) 

J. Chapman - FSD, White Sands ° 

P. A. DePascale - LA Federal 
W. B. Gibson - MOL Project 
J. E. Hamlin - FSD MOL Project 
H. G. Hoyt - LA Federal 
J. Jones - FSD, LA Aerospace Bldg. 

P. O. Lindfors - FSD, LA Aerospace Bldg. 
M. Martin - FSD, White Sands 
C. E. McKittrick, Jr. - FRO (GEM) 

J. H. Priday - LA Federal 

J f J. Selfridge - FSD MOL Project 

R. Stanley - LA Federal 

R. Ur sin-Smith - FSD, LA Aerospace Bldg. 
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DEBRIEFINGS 


In Air Force fashion, each IBM attendee was asked to jot down his 
recollection of comments made by personnel during the meeting. These 
are as follows: 


W. B. Gibson 

Col. Montalvo: Come see operations. 

I am integrated now. 

Same pitch as you made 18 mo. ago only using flip 
charts instead of slides. 


Col. Carey: 


Col. Hill: 


We agree in concept. 

We want your detailed design. 

(to J. Jones) Your date is way too optimistic. We 
need a system in February, 1967, not October 1967. 
(to J. Hamlin) Our biggest computing problem is a 
five station real-time fix for radar tracking. 

We have a good operation now. It is proceeding on 
schedule. 


(Col. Hill is not yet completely identified as to 
what organization he represents) 

Mr. Kraff: What information do you need from us to make a 

design? 

Col. Carey: I want a real-time data bank with multiple access to 

it from users all over the range. 


I understand why the computer operation should be 
closed but the data must be open. 


I could care less whether' there is one or multiple 
systems required to do the job. 

What I am interested in is square footage, people 
and dollars required. What are you going to do about 
our Range Automated Information System? We want 
details and specific recommendations from IBM. 
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J. E. Hamlin 
Maj. Corley: 

Mr. Don Hass: 

Mr. Kraff: 

’67 

*68 


Section 3. 4.1 


Interested in managers .it remote inquiry devices 
and methods vs. logistical and schedule information. 

Asked mundane, courtesy question. Can't recall 
content nor answer. 

Agitated as hell. Really wanted IBM to come in with 
specific design. Wanted following dilemma identified 
to General 


6595 


WTR- 


NRD - AFSC 


TMCC 


RCC 



'67 


5 , 


6 , 


Bldg. 300 


7 , 


Basic conflict between centralized facility incorporating 
computers 1, 2, and 3 vs. second facility(ies) incorpo¬ 
rating computers 4, 5, 6, and 7. Many of these buildings 
and computers are already in the approved plan. 

He talked of the problem in use of Facilities for Headquarters 
purposes. He emphasized need for evolutionary growth 
within presently planned budget. Pleaded for correcting 
seemingly duplications. Will collaborate with EBM. 

Wants to know how to get to General again. He suggested 
series of design cooperative efforts. 

Pointed out preface statement of recent IKC6 report on 
computers. 

He had. hoped that case would be made for continuity of 
effort from fabrication to checkout to mission. 
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J. Jones 
Gen. Bleymaier: 

Col. Carey: 


Col. Hill: 


J. H. Pridav 
Col. Carey: 

Col. Montalvo: 

Col. Hill: 

Mr. Kraff: 

Section 3. 4.1 


1. He’s learning - there are problems. 

2. WTR is' going the consolidated approach. 

3. There's still some work to do. 

4. Like to talk to us some more. 

5. Accepted what we had to say, liked it. 

Apologized to Jim. Wasn't trying to shoot down the 
pitch. Just wanted to tell us we were way ahead last 
year. They are just catching up. Have to have design 
to get approval. Doesn’t care where computers are 
as long as they are together and you have communication. 

No dedicated computers. Five stations for probably 
biggest job, FORTRAN IV official language NRD. Wants 
to put Air Force management system on a file. Wants 
management information system. Wants remote terminals 
for management information system. Wants us to come 
see him. 

Has lots of ideas and requirements. Doesn't know 

how he will get to answer WTR and 659th planned 

facilities to go together. CTC a sore spot that has to 

have continual money. Can't chop it out. Doesn't see why you 

canlt furnish 72-hour tapes at the same time you plot 

range safety present position. 


Management Information System. 

February, 1967. 

No study. 

I have a consolidated computer. 

What do I do to this facility? 

He hasn't seen anything new. 

Doesn't want consolidated. 

Havent defined existing operational problems and future 
requirements. 

Wants us to tell him what information we need. 
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J. J. Selfridcre 
Mr. Radom: 

Lt. Col. Montalvo: 

Mr. Radom: 


Mr. Radom: 


Section 3. 4.1 


(In his office afterward) 

"You got to the general. We have some operations 
people problems and I’ll take care of them. " I told 
him what Bleymaier told Jones (i. e ., we were on the 
right track). Then we were joined by 

Montalvo said, "You guys should have given us a design 
to pick apart. What you said today you said 18 mo. ago 
We've got a system now. We want you to tell us your 
ideas." 

"You were pitching preliminary design and it couldn't 
have been done without Wing and Range ties. " 

They both indicated that the 659th was not formally 
a part of AFWTR. 

Montalvo left. 

"We've got some operations types looking down a 
hole with blinders on." I told him that we could very 
easily have pitched equipment but decided against it. 

He said, "You made the. right decision. If you had 
pitched IBM numbers, you would have gotten ten times 
worse treatment. We needed concept of starting 
from scratch. We can work with you now. I'll call 
Gibson on Friday. " 


### 
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November 18, 1965 


C. Tross 


PART I. 

TO: Distribution 


COMPANY CONFIDENTIAL 

TRIP REPORT: VISIT TO 


On 11/16/65 the writer visited the Western Test Range and spoke with 
Mr. Stan Radom, Colonel Hoffman, and Mr. Hallenbeck. 

The visit was arranged for the writer to re-establish his contact with 
range personnel and explore their current interests and future require¬ 
ments for the range. 

The first meeting was held with Mr. Rado.m. We discussed the presenta¬ 
tion given to WTR by IBM on 11/10/65 concerning the "Integrated Control 
Center Study". Mr. Radom made the following comments: 

1. The presentation was made at his request and he coordinated 
the attendance invitations to WTR personnel, which included General 
Bleymaier, Commander WTR. 

2. He felt this presentation was generally well accepted, however, 
some attendees had hoped for more details and were hostile. 

3. He quite satisfied with the expressed interest on the part of 
IBM and especially the desire to provide the preliminary services being 
expended during the next month. 

4. He also states that GE and CDC are conducting similar studies 
at this time. 

5. Since some of the people were not completely sold by the pre¬ 
sentation, a great deal of emphasis shall have to be placed on the report 
and possible presentation, which will take place in mid-December. 

6. At the present time the ICCS is the principal thrust effort at 

the range. It is hoped that this center will be active and useful for the MOL 
program with which the range is significantly preoccupied. 
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Meeting with Colonel Hoffman 


1. Colonel Hoffman, in effect, relayed the same personal 
observations as Mr. Radam. 

2. Sperry Gyroscope has contacted Colonel Hoffman in regard to 
the ICCS but it seems they were not encouraged to participate. 

3. He is quite interested in using a Multi-Station Solution in the 
center. 

4. He pointed out that since radars cannot provide comparable 
accuracy to inertial platforms, range safety officials have agreed to 
employ platform data in range safety displays. This, he feels, is a major 
break through. 

5. In view of the cost and weight of the transponder. Colonel Hoffman 
feels that GERSIS (which uses the GE-Mod III radar and COTAR) is no longer 
of particular importance. He thinks the range should eliminate this system. 

6. At the present time an RFP is being prepared,the first version 
of which has been reviewed by Colonel Hoffman but was returned for 
revision. He thinks clarification and more detail is desired in this RFP. 


Meeting with Mr. Hallenbeck 


1. Mr. Hallaway reflects similar impressions to those offered by 
Mr. Radom. 

2. * He stated that ICCS mission definition is not very clear at this 
time. Although a number of range personnel are addressing this problem, 
no definitive definition exists at this time. 

3. Mr. Hallenbeck elaborated on his job and responsibilities. He 
reports directly to Colonel Hoffmann and is responsible for the engineering 
budget. At this time he is occupied with the preparation of the FY'67 budget. 
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Thereare three fundamental and distinct budgets at WTR which may not 
draw on one another. He did not offer any information as to budget 
magnitude, however, stated 11 It is much more difficult to obtain money 
in the Air Force than it was in the Navy. " n If you think we had it bad at 
the Navy you should see it now. n 
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PART II 


November 18, 1965 

To; 

Distribution 


From: 

C. Tross 


Subject: 

Trip Report - Visit to PMR 



On Nov. 17th I visi ted Mr. Henry Settle at PMR. A general discussion was 

held pertaining to his current efforts and interests. He stated that: 

1. The RTDHS programming task is currently being executed by Informatics 
under a $9OK contract won as a result of a select source competition in 
March 1965. 

2. Integration of RTDHS and IDDS is being effectively conducted by Collins 
and Range Development personnel. 

3. The RTDHS-IDDS control center has been designed and will be located, in 
Bldg. 50; it is intended to be a rather comprehensive center. 

4. The ROMAC program has now been completed by ITT. Equipment for this 
system has been received and integration is scheduled to be undertaken 
by Range Operations personnel. 

5. The range is currently interested in activities related to the Pacific Test 
Range and the Hawaiin Undersea Test Range. 

6. For the moment, Settle knows of no new systems development plans. He 
suggests, however, that we contact Dr. Dudsziack in Santa Barbara (for¬ 
merly with TEMPO), who is still a principal test consultant with substan¬ 
tial influence at DASA. He feels that new support-type programs may be 
in the making. 

7. Mr. Settle gave me copies of Informatics report on RTDHS and Collins re¬ 
port on IDDS/RTDHS. These reports should be helpful in RICC. 

C. Tross 
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November 3, 1965 

TO: Mr. J. J. Selfridge 
FROM: F. X. O' ourke 

INITIAL THOUG1 S CONCERNING IMP Li ENTATION OF THE DIGITAL 
CHECKOUT FAC ,TY AT THE WTR LAU H COMPLEX. 


In an area as com; ehensive and overs. ' vehicle checkout 

and validation, the writer cannot . me to Tnitive 

recommendations on the subject uni*.- . .as ii a great deal 

more specific engineering information regarding plan:.. equ^. it con¬ 

figuration, proposed test and checkout approach, as well as the general • 
operational criteria associated with the launch of the particular vehicle. This 
data, coupled with specific launch objectives and broad launch schedules, 
would allow the presentation of system engineering ground rules more 
directly geared to insure the orderly rapid and successful development of a 
useful computer checkout complex facility. 

However, it is the writer's opinion that experience gained in designing and 
implementing a job such as a launch control system for the Apollo launch 
vehicle has highlighted some very pertinent general engineering considerations 
which should be carefully taken into consideration in the development of any 
hardware/ software checkout capability to be used for validation of Apollo 
or Titan type vehicle. While many of the following recommendations can 
easily take on the aspect of self-evidency or patently good engineering 
procedure, the writer would like to stress that most of them, were completely 
overlooked in the initial design of the existing Saturn launch computer 
complex and, in many cases have deteriorated the utility of the system to 
such an extent that formal engineering notification has been transmitted by 
IBM to NASA expressing the high probability that the existing launch computer 
complex will be unable to launch a Saturn V vehicle without a material mod¬ 
ification to the system either through the additional computer capacity or 
the relegation of prime control functions to ground support hardware in place 
of the Saturn launch control computer. 

Assuming, for this discussion, a checkout and launch facility is required 
for the Titan III vehicle and that some semi-automated computer checkout 
capacity is desired, the following ten basic ground rules should be thoroughly 
investigated prior to layout of the initial system configuration: 

1) Operational experience being ghined now at launch complex 34 
and 37 clearly highlights the undesirability of a two-computersystem with 
one'computer very close to the vehicle and the other in the blockhouse. In 
practice the existence of a completely implemented computer facility close 
to the vehicle has proved very difficult Id utilize during the final pases of the 
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To: Mr. J. J. Selfridge 


November 3, 1965 


countdown and in event of failure or misoperation leaves the operational 
launch control group completely helpless to take remedial steps for even 
the slightest malfunction, since the launching procedures allow no person 
in the area during final phases of the countdown. As a result of this problem, 
every effort is now being made in the Saturn facility to remove all major 
control and test programs from the computer located nearest the vehicle 
in such a manner that in the final phases of countdown the vehicle (AGSC 
computer) is in a passive monitor status with as much control as possible 
relegated to the blockhouse computer. While complete discussions of this 
particular problem are outside the scope of both the paper and the time 
writer has to prepare it, the basic criteria of limiting computer hardware 
as much as possible to those input and output devices required to fee the 
central control processor cannot be overemphasized if the checkout system 
is planned for use during a launch countdown. 

2) Evidence clearly indicates that "even checkout system s, 
utilizing computers, starting out with the purest intentions of remaining 
completely passive at some time in their development require the 
generation of control functions from the checkout computer to the launch 
vehicle system under test. The insertion of this control capability into the 
checkout computer system will rapidly evolve into a basic requirements 
(generated by range operational personnel) to utilize the computer system 
as an active control element during launch operations. If this possibility 
exists, care should be taken in the initial design of the computer facility to 
provide adequate high-speed data channels to allow the full potential of 
the computer facility to be eventually realized. Asa minimum, means 
should be provided in the data link communication system from the computer 
to the vehicle to allow all control functions to be transmitted completely 
independent of monitor functions and data being transmitted from the 
vehicle to the computer. As a minimum, it would seem this would take 
the form of separate 
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January 17, 1966 

L. A. Westchester GEM - 230 


Su!„cct: CTCS - WTR 

Rc'cr ,Your memo to H. G. Hoyt, 1/4/66 






To: Mr. J. E. Hamlin 
MOL. Project 



Due to delivery requirements, the Universal Telemetry System RFP 
for CTCS will be no T bid. A technical report will be submitted to 
Col. Hoffman, Director of Range Engineering, describing a system 
that would meet the technical requirements of the RFP. The purpose 
of the report will be to delay delivery requirements and to demonstrate 
IBM's capability in this area. Target date for submission of the report 
is January 25, 1966. Presentations by F. Mutz and myself upon sub¬ 
mission are also planned to further strengthen our recommendations. 


It is expected that WTR will also be letting an RFP about Feb. 15,- 1966 
for a computer system to perform "fault analysis" and control of the 
entire CTCS facility. Personnel knowledgable in telemetry processing 
are presently being sought within IBM to meet this land future telemetry 
bids at WTR. Subcontracting or teaming arrangements are not recom¬ 
mended due to the extreme need of building and retaining in-house 
capability in this area. 


JHP:ep 


3 

J. Priday 


cc: H. G. Hoyt 

P. DePascale 
J. Warstler 
F. Mutz, FSD 
W. Gibson, MOL 
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MEMORANDUM TO FILE 


FROM: J. E. Hamlin 

SUBJECT: Trip Report on Visit to MCC - Houston, with 

Major Hartrim and 'st Lt. Smith of the 6595th 
Test Wing 


Major Hartrim requested that IBM personnel accompany him and 
Lt. Smith on a visit to Houston Control Center. I advised him to 
make arrangements through military channels. The visit was made 
with myself and Mr. Jay Priday of the Data Processing Division 
accompanying Major Hartrim and Lt. Smith. 

During the flight down, we discussed the general agenda, which 
covered the following items: 

Trajectory calculations 

Simulation 

Crew environment data 
Post flight data reduction 

Programming system design, particularly 
how changes were incorporated 

Brief discussion on the tradeoffs of the relative 
costs of space, between office space and that 
for electronic equipments. 

We met in Houston at the Alpha Building on Monday morning at 
approximately 9:00 a.m. We had a brief discussion and Major 
Hartrim checked with Colonel McKee's office and determined that 
he had failed to make proper arrangements through military channels 
and so some time was wasted in military protocol. We did, however, 
meet a Colonel Ballantyne, who is the MOL coordinator for the 
Space Systems Division of the Air Force at Houston, for working 
relationships with NASA. I gained the impression that in this 
capacity. Col. Ballantyne works for a General Burke. Mr. Priday 
and I toured Major Hartrim and Lt. Smith through the Control Facility. 
Lt. Smith is a little difficult to work with, in that he interjects 
questions and engages in give and take discussion. However, 
we did manage to describe the operational aspects of the control 
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center, the data flow, the functional use of the computers and some 
of the other features. Smith engaged in conversation as to relative 
merits of display system. I don't think we did too good a job in des¬ 
cribing to him the reasons behind the design. He was openly contemptu 
ous of sorre of the design that he found in Houston, making statements 
such as the Air Force would surely want a system that was simpler in 
design or more efficient in operation. I judged that Major Hartrim is 
a real strategist. He has been in the Air Force a length of time and 
before that told us that he had been an enlisted man in the Navy. He 
described how the CTCS system came to be established, wherein they 
had taken common equipment from each launch complex and consoli¬ 
dated it into one facility. He described the fashion in which he had 
obtained SAC cooperation to provide the building, by promising them 
the system when it became operational and how, later, he arranged to 
have a higher level command renege on the obligation. He described 
further how it had been planned to turn over this facility, which was 
inadequate to the WTR, such that the Wing would be free to procure 
the TMCC. He went on further to describe that the Wing had money 
for a TMCC and had preliminary design in mind;, he described that the 
TMCC would be implemented in a step-by-step phasing manner and 
that it would be done in order to support the MOL. Clearly, there is 
a need for additional marketing to be done in the area, and we must 
learn more details about the organization of the Wing. 

Major Hartrim did say that the Commanding General of the Wing, 
Colonel Newton and his deputy, I think a Colonel Greede, were 
retiring. He and Colonel Ballantyne had discussion on this point, 
on the relative difficulty of keeping competent military officers in 
the Service when they were no longer qualified for flying status. 

I think much of the discussion was for the benefit of we civilians 
who were standing there who they obviously believed made too much 
money. 

Major Hartrim said that the CTCS computer bid had been killed but 
that some of the people on the base had not been advised of this 
yet. Both Hartrim and Smith portrayed a feeling of self-sufficiency 
on the part of the Wing. They indicated that they had had discus¬ 
sions with CDC but not any great amount of discussions with 
UNIVAC. He further said that they had had very little or no discus¬ 
sions with Philco. He was amused by the fact that the majority of 
the contractors and vendors have given attention to WTR and have 
overlooked the Wing. We determined that the TMCC would not 
include the range safety function nor normal data reduction. We also 
determined that the TMCC would be oriented from the standpoint of 
telemetry data input and data reduction and mission control, as 
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derived from telemetry-type data. They are specially interested in 
checkout. Their concept is that the TMCC would have a central type 
of data handling and computing and that the launch control would be 
obtained by remote display that could be fairly flexible or movable 
and the driving distances from the Control Center TMCC to the launch 
display might be in the area of 5 miles. They gave strong emphasis 
to the minimalization of equipment throughout the total system. They, 
in my judgement are looking for a fully integrated system and a single 
contractor. At this point I believe, from my discussions with them, 
that they would recommend both hardware and software in one contract. 
They implied an RFP in approximately three months. They said that the 
TMCC building was actually underway. 

They will have further discussions with Philco in Houston on the 
Control Center and after that plan to go to Cape Kennedy, where they 
intended to tour the Merritt Island facilities and the Control Centers 
on Cape Kennedy. They might also have planned to go to the Data 
Reduction Center at Patrick. 

I believe it would be profitable to get back for further discussion 
with Major Hartrim in the area of checkout and in the areas of launch 
control. I think that he and Smith would be quite candid in terms of 
what their system design approaches are. I am sure that they have a 
very close working relationship with CDC. This was indicated by the 
fact that the CDC salesman, a Tom Gorman, was with these gentlemen 
Sunday afternoon at the time they ordered the airplane. 
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GEM Region 
Air Force Programs 
Washington, D.C. 

December 2, 1965 


MEMORANDUM 

TO: Mr. W. B. Gibson 

L. A. Aerospace Building 

SUBJECT: Western Test Range 


I have learned that plans to merge the 6595th Aerospace Test Wing into WTR 
have been scrapped. WTR will take over some of the space in the building 
which houses the 6595th. 

National Range Division is aware of WTR‘s present study of CRCC, and wi II 
be interested in seeing the results of their study. In order to sell a program 
for CRCC to NRD, WTR's pitch should show WTR as a component part of the 
larger Global Range System which includes ETR and SCF. Great care should 
be taken to show how easily WTR can interface SCF and ETR, and where 
system compatibilities can be effected. 



R. P. Bruns 


RPB: i Is 

cc: Mr. J. W. Richardson 
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Weekly Activity Report on WTR Project 
12/3/65 


H. G. Hoyt 
Branch Manager 


Calls were made on Gene Clary, John Payer, Major Olson and Dave Huffman 
by Bill Gourlay, Gene Rogers and Dick Stanley. Purpose of the calls was to 
gather information on installed Data Handling System and Communication 
System. Documents were obtained to assist in documentation of present system. 

Meeting with Major Conley, Chuck Leroy, and various people from the 
Command and Control section of Range Engineering was attended by Dave 
Nichols, Michel Bibault and Jay Priday for discussion of the WTR project 
and in particular the Management Information System of the project. In j 

addition to the discussion on the local requirements for Management Information 
System, it was learned that $4, 000,000 was planned for the military construction^ 
program at W r TR for the fiscal year *69 for a Consolidated Range Control Center . 
Installation of equipment into the CRCC is planned for fiscal year *70. This 
represents a one year slippage in previous plans. Major Conley also indicated 
that the Consolidated Telemetry Checkout Station will be turned over to W r TR 
on 1 January 1966. Finally, it was learned that the preliminary Range Package 
Plan that was submitted to NRD November 15 will be back to W r TR on December 
15. At this time the Range will prepare the final version of the long range 
plans and submit the final version to NRD on January 15, 1966. The Range 
hopes to incorporate into this planning document information that we submit 
in our technical reports on the Consolidated Range Control Center. 

Timing kernels were submitted to Jim Alexander, Range Operations, 
comparing the 7094 Mod 1, 7094 Mod 2, 360/65, and 360/75 on a representative 
scientific job mix. These kernels were taken from the Force proposal that 
was prepared by the Federal Region and Poughkeepsie groups. 

The Fall Joint Computer Conference was attended Vy Bert. Lery, John Spellman, 
and Jay Priday. Bert Lary is in the Systems Engineering group of Range 
Engineering and John Spellman is an engineer for the Autonetics Division of 
North American and is active as a consultant to both the Western Test Range 
and the 6595th Test Wing. A special demonstration of our 360 system at the 
conference was arranged and discussions on the Consolidated Range Control 
Center were accomplished at the conference. 
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Page 2 


Mr. Frank Mut*, formerly FSD Project Manager at JPL, is now FSD Project 
Manager at the Western Test Range. Mr. Mufcr arrived in Lompoc on Friday 
and started to familiarise himself with the project. 

A preliminary telemetry systems design was started by Paul Lindfors, 

BUI Fulton, and Jim Hamlin. Mr. Fulton is a consultant hired by FSD for 
the telemetry design. 

A preliminary outline of the technical report to be presented to the Western 
Test Range was prepared by Dick Stanley and Jay Friday. Following are 
the major subject areas for the report: 

Executive Summary 
System/360 Hardware 
System/360 Software 
Data Reduction 

On-Line Real Time Operational Support 

Telemetry System 

Communications 

Instrumentation Checkout and Diagnostics 

Management Information System 

Detailed Systems Design 

Hardware Cost 

Software Cost 

Physical Planning 

Facilities 

Target date for submission of technical report to the Western Test Range 
is December 15, 1965. Maximum effort will have to be expended by project 
team in order to meat this target date. 



J. H. Priday 


JHP/mb 

cc: Paul DePaseale* LSG 
Bill Gibson, MCL 
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Date: 

February 10, 1966 

L. A. We stche ster GEM - 230 


From (Dept Loc): 

‘l fj V, r 1 

jlephune Ext.: 




Subject: MOL Planning at Vandenberg AFB 


Reference: 


To: W. B. Gibson 

MOL Project 




Plans for supporting MOL are now under way at Vandenberg AFB 
by both the Western Test Range and the 6595th Aerospace Test Wing. 
Range safety and communication of orbital parameters to the mission 
control center will be the responsibility of WTR. Pre-launch check-out 
of booster and vehicle, simulations, and biomedics are requirements 
that the 65 95th are now planning for. 

WTR will perform their functions on the existing 70 94/7044 system. 
Processing of radar data will be performed by the 7044 while the 
guidance data from the telemetry system will be handled by the 7094. 

No firm plan is now in existence if redundancy of computing systems 
is a requirement. Discussions with WTR personnel indicate that if 
redundancy is a requirement, four alternatives will be explored: 

1. Duplication of existing 70 94/7044 system. 

2. Replacement of present systems with a dual 360/40 
or 360/65 configuration. 

3. Replace the 7044 with CDC 3600’s to handle all real 
time requirements. 

4. Provide real time inputs to both 7094 and 7044 and 
essentially split the system into two separate com¬ 
puting systems. 

Extreme pressure is now being exerted on WTR from NRD to install 
the 3600’s so that standardization of computing systems at ETR and 
WTR can be accomplished. WTR is taking the position that the Range 
is meeting its real time and data reduction requirements on a single 
direct couple system and hence, additional computers are not necessary. 
In fact, current plans are fairly firm to award FSD a sole source contract 
to provide WTR with a software package to incorporate present real time 
and non-real time programs into a DC system similar to the one at 
White Sands. 
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Duplication of present DC system to meet MOL requirements is 
rather remote unless systems within the government's inventory are 
available. 

Replacement of existing systems by third generation equipment 
could be effected by an RFP late this year with installation date FY '68. 
This would be in line with WTR's plans to relocate and consolidate 
all Range computers into a single Consolidated Range Control Center 
(CRCC). Approval for the CRCC depends on whether or not the 6595th 
gains approval for their planned Technical Management Control Center 
(TMCC). 

Splitting the two systems and giving the facility some resemblance of 
redundancy is not favored due to increased cost in both hardware and 
software without an appreciable increase in capability. 

In the area of pre-launch check-out, etc. the 6595th is moving very 
rapidly to gain approval for the TMCC. About $2. 5 million has 
already been approved for a building and approval for equipment money 
is now being sought from General Shriever. Presentations by the Test 
Wing and local Aerospace Corporation personnel to General Shriever 
was supposed to have taken place during the week of 2/4/66. Concept 
approval has supposedly been obtained from General Cooper and General 
Bleymaier. 

Specifications for an RFP are now being generated by personnel from 
the Test Wing MOL Project Office (Major Hartrim and Lt. Smith). 
Hartrim and Smith toured various facilities in the country during the 
week of 2/4/66, looking at design approaches and contractor capabilities. 
Jim Hamlin and I accompanied Hartrim and Smith to Houston, where we 
toured the RTCC. The following information was obtained from the trip: 

1. Approximately $20 million is available for the TMCC. 

2. If approval is obtained, an RFP will be out in the second 
or third quarter of this year. 

3. A single contractor for system design, hardware, software, 
integration, ONM, etc. is mandatory. 

4. Design will call for five telemetry processors to perform the 
decommutation and data compression functions. 
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5. Two main processors to perform the data analysis and 
display formatting will also be called for. 

6. A telemetry oriented software system, similar to STOLL 
being developed for the CDC 924 at Douglas Aircraft, is 
needed. 

7. The TMCC will be used for all MOL work at WTR. No 
special contractor-provided systems will be allowed. 

8. The function of the Consolidated Telemetry Checkout Station 
(CTCS) presently being run by WTR for pre-launch check-out 
of ballistic weapon systems will be transferred to the TMCC 
with the result that CTCS will no longer be needed. 

9. CDC will probably be bidding five 1700's and two 6400's 
and Hartrim and Smith lean toward their approach. The 
WTR CDC representative, Pat Gorman, accompanied 
Hartrim and Smith to the L.A. Airport. 

10. Philco is not held in very high esteem by the Test Wing. 
Lockheed's status unknown at this time. 

11. Hartrim and Smith were planning sessions with Philco in 
Houston, CDC at the Cape, and GE in Philadelphia, on their 
trip. 

12. Approximately twelve CRT displays and associated control 
equipment will be required per launch complex. There will 
be approximately eight to ten such complexes needing this 
capability. 

13. Equipment deliveries will be in the early 1968 time period. 

It must be emphasized that the above information was obtained from local 
Test Wing personnel. No information is available at this time at the SSD 
or AFSC levels to verify the above is being done by the 65 95th. Although 
it was indicated that General Bleymaier had approved of the TMCC concept, 
talking with local Test Range personnel indicates no decision will be made 
on the TMCC until organizational problems are ironed out between the 
Test Wingand WTR. 
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In the event, however, that the Test Wing does gain early approval for 
their plan, the following marketing plan has been established: 


1. Perform preliminary system design. This includes design 
philosophy, standard and special equipment needed, RPQ's, 
and special CRT displays. 

2. Establish software requirements, including special telemetry 
oriented language. Presentation of the telemetry software 
system proposed at White Sands is planned in the near future 
for Test Range personnel. 

3. Establish a preliminary implementation plan - one of the 
tough ones. Define areas in which IBM has the capabilities 
and discuss teaming relationships for that part of the plan 
where IBM has no capability. 

4. Determine equipment availability. 

5. Arrange for hardware/software presentations at Poughkeepsie 
plant. 

6. Obtain comparative analysis of expected CDC system. 

7. Obtain SSD thinking on TMCC concept. 


.The above marketing plan should be accomplished by April 1, 1966. 

n . 

c-i 


JHP/mb 


J. H. Priday 
Account Representative 


cc: R. P. Bruns, Wash. 

H. G. Hoyt 
P. A. DePascale 
J. E. Warstler 
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February 23, 1966 


MEMORANDUM 

TO: Mr. M. J. Priday 

Los Angeles Westchester GEM 

Mr. John Warstler 

Los Angeles Westchester GEM 


SUBJECT: 


Consolidated Range Control Center - WTR 

Technical Management Control Center - SSD Aerospace Test Wing 


As you are aware, determination of which organization will proceed with establishment of 
its control center will be made at General Schriever's level. A group from WTR is scheduled 
to brief HQ NRD during the week of February 28, in order to prepare General Davis 1 staff 
for selling WTR's CRCC to Schriever. This parallels the recent action of the 6595th Aero¬ 
space Test Wing in taking their justification for TMCC through SSD to General Schriever. 

The consensus of opinion at HQ NRD now is that 

(1) there is considerable economy to be gained by establishing a CRCC; 

(2) the CRCC should be managed by WTR very much in accordance with present 
philosophies, i .e. that WTR provide standard services, facilities and data 
to users; 

(3) the CRCC building should provide space for Range users, like the 6596th, 
where the user provides his own equipment for satisfying mission-peculiar 
requirements. 

Certainly there is something to be said for NRD's approach. Consolidation, centralization 
and sharing of facilities will satisfy those concerned with budget pressures. Management of 
the facility by WTR is within the presently stated mission of WTR, hence no organizational 
changes would be in order. Finally, the user would have an avenue to provide his own 
capability when mission requirements dictate such. 

I will continue to follow this project at NRD HQ, and advise upon on its program. 


R. P. Bruns 


RPB: mr 

cc: Mr. H. G. Hoyt, B/M, Los Angeles West. GEM 

Mr. P. A. DePascale, Los Angeles West. GEM 
Mr. W. B. Gibson, Los Angeles Aerospace MOL 

Mr. J'. W'. Krchardion, Local Page H/35 
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GEM Region 
Air Force Program 
Washington, D.C. 

, March 7, 1966 

MEMORANDUM 


TO: 


Mr. J. Priday ) Los Angeles Westchester GEM 
Mr. J. Warstler ) 


SUBJECT: Consolidated Range Control - WTR 

Technical Management Control - SSD 6595th 


Determination of which organization should proceed with its plans to establish a 
control center will be made in a few days. As I indicated in my February 23 
Memo, NRD favors the WTR managed CRCC. It is very clear, however that NRD‘s 
support of CRCC at General Schriever's level will not be particularly strong. 
According to Colonel Creighton, assistant to the Commander, NRD is 51 % for CRCC. 


It is clear then, that we must continue to concentrate on influencing the 6595th at 
Vanderberg as they develop specifications for the TMCC. 



RPB:mr 

cc: Mr. H. G. Hoyt, B/M, Los Angeles Westchester GEM 

Mr. P. A. DePascale, Los Angeles Westchester GEM 
Mr . W. B. Gibson. Los Angeles Aerospace MOL 
Mr. J. W. Richardson, Local 
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MOL STANDARDIZED CALL/TRIP REPORT 


Customer/Prospect Name (1) IBM, Lompoc, California _(15) 

Individuals ) contacted (16) F. Mutz, R. Ursin-Smith, W.Green,W.Grisham, (59) 

J. Gray/ R. Hippe 

Your Name (60) W. Gourlav, F.X. O'Rourke (70) Date (71) March 24-25 . 1966 (76) 

Summary of Facts Covered: 

1. An orientation and direction conference was held on March 24-25, 1966, at 

the Lompoc Office, regarding the AFWTR Consolidated Range Control Center (CRCC), 
the AFWTR Consolidated Telemetry Checkout System (CTCS), and the 6595th ATW 
Technical Management Control Center (TMCC). 

2. Integration and organizational reassignment of F. X. O'Rourke and W. Gourlay, 
Jr., from Department M48 to Department M49 was discussed between F. Mutz and 
the principals involved. 

3. As a subset of the effort in automatic checkout, a demonstration (simulation) 
on the IBM 2250 is desirable. D. Lee and J. Gray are assigned to program the 
demonstration, with half-time programming assistance from P. L. Hertan. D. Lee 
and R. Cabaniss are presently programming a demonstration for the USAF Satellite 
Control Facility. It is expected that much of this experience will be directly 
applied to the checkout simulation. R. Hippe is addressing the problem of avail¬ 
ability of a machine for the demonstration. Preliminary display simulator require¬ 
ments reflecting the concept contained in the Preliminary Design Specification 
document have been completed. These simulation requirements are in sufficient 
detail to warrant a complete review with the assigned programmers prior to 
finalizing the approach. 

4. The USAF political situation at Vandenberg AFB was briefly touched on. It was 
decided to address the general need for an integrated modular approach to the next 
generation of "on line" aerospace ground computer complexes, while maintaining a 
capability to respond to either a total or segmented specification as required. 

5. Summary 

a. The display specification for the Simulator is in sufficient detail to 
commence the initial programming effort. 

b. Equipment availability is unresolved at this time and will have 
important effect on the entire schedule. 

c. Content of simulation demonstration will be determined by March 30, 1966. 

d. D. Lee and J. Gray are assigned to program this demonstration. P. L. 
Hertan will be assigned to assist on a half-time basis about 3/30/66. 

e. F. Mutz and R. Hippe have reviewed the initial simulator concept and 
are in general agreement. 

f. The goal of this group is to have initial flow charts and coding well 
under way by April 1, 1966. 

WG/jh 

cc: C. B, Brown, J. Gray, 

W. B. Gibson, R. Hippe, F. Mutz 


Gourlay 0 



■"L.. 
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Memo to: R. P. Bruns, GEM Region 

P.A. DePascale, LSG 
.k'W. Gibson, MOL 
H. G. Hoyt, LSG 
F. E. Mutz, FSD 
R. K. Rea, LSG 
J. W. Richardson, GEM Region 

Subject: Consolidated Telemetry Checkout Station (CTCS) 

at Yandenberg AFB 


An RFP is expected within the next 30 days from the Western Test Range 
(WTR) for a telemetry system to perform pre-launch checkout of ballistic 
missile systems launched from Yandenberg AFB. 

Due to the complexity of the proposal and the severe impact that it has on 
IBM’s future at Yandenberg, this memo is being written to define in detail 
the situation that exists so that the various IBM offices involved can be kept 
abreast as to the status of the project, our plan of action, and the support 
we expect to solicit in order to win. 

The CTCS was conceived and developed by the 6595th Aerospace Test Wing, 
located at Vandenberg AFB, to bring about a better cost effectiveness approach 
to the function of pre-launch checkout of missile systems. The purpose of the 
CTCS is to provide a common set of equipments, in a single facility, and 
available to all range users to perform the pre-launch checkout of their 
respective missile systems. This consolidation has taken place in the area 
of ballistic system checkout and as of January 1, 1966 the facility was turned 
over to the WTR for operation. The 6595th is now planning for a multi¬ 
computer complex called the Technical Management Control Center (TMCC) 
to provide a capability for performing the checkout of not only ballistic systems, 
but also all space systems including Titan III and MOL. The CTCS will 
eventually be replaced by TMCC and equipments compatible with the design 
approach of TMCC will be transferred. In fact, all future procurements for 
CTCS, including the expected above-mentioned RFP, will have to be in line • 
with the TMCC design. It is essential, therefore, that we win the upcoming 
CTCS RFP. It has not been resolved as to who will control the TMCC, either 
the 65 95th or the WTR, but in any case our strategy remains the same no 
matter who wins control. 
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The CTCS RFP will be a total system bid that will include computers, 
special telemetry equipment, software, and system integration. The RFP 
is expected by May 1, 1966 and will call for a 30-day response, a 30-day 
evaluation, and equipment delivery 225 days after contract award. The 
range is now considering purchase of all equipment with approximately 
$1. 35 million of FY66 money available for this procurement. 

Information from the range indicates that the specifications will call for 
computers with a 1 /asec memory cycle and 24 bit or greater word length. 

Preliminary system design using a dual Model 44 configuration is shown in 
the attachments. Purchase price for this system is approximately $1.2 
million and this does not include special front end equipment, software, or 
system integration.' At this time we do not have a dollar estimate on these 
additional items, but it is evident that we exceed the budgeted dollars by 
quite a bit. At this time work is being performed to reconfigure the system 
and reduce the overall cost. In addition, a single Model 44 configuration 
is also being studied to determine its effectiveness on the CTCS requirements. 

A block diagram of the hardware system that is expected in the RFP is 
shown in the attachments as well as the functional requirements for the 
system. It is not known at this time as to what software specifications 
will be included in the RFP. Local SDC personnel are working on software 
specifications and it is expected that they will write performance specifications 
similar to the approach taken at the SCF for the telemetry processing. 

In the area of front end processing FSD’s Engineering Lab is investigating 
the use of a ROS system to perform the frame sync, subframe sync, limit 
checking, etc. The system is called the Adaptive Mi crop rammed Control 
System (AMCS) and it appears to have significant application in the area of 
telemetry processing. Engineering Lab personnel have been briefed on the 
CTCS requirements and are presently performing a preliminary system design 
using the AMCS and Model 44‘s. In order to consider the AMCS, commitments 
by FSD on delivery, and costs will have to be obtained within the next 30 days. 

Competition will come from both computer manufacturers and the special 
purpose telemetry industry. Following are the manufacturers and systems 
that are known to be actively pursuing this bid: 

CDC - 1700, 3100 
SDS - 92, 930, Sigma 7 
DEC - PDP8, PDP7 
Telemetrix - 670 
Beckman - 420 
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This will be the second procurement the WTR has had for CTCS this year. 

We were forced into a no bid decision on the first procurement due to a 
90-day delivery requirement and the unavailability of the 1800. Lear Siegler 
won this procurement with a PDP8 and Telemetrix front end equipment. 

It is expected that our toughest competition will again come from Lear 
Siegler who will be bidding a PDP system, and CDC with their 1700. 

Due to the total system aspect of the RFP, FSD will be submitting the 
proposal. The proposal will be a joint effort by Vandenberg DP and FSD 
personnel and FSD's Engineering Laboratory technical staff. A summary of 
the tasks to be performed by this group and their scheduled end dates are 
shown in the attachments. 

Our proposal strategy to date is to design a system that meets both the 
CTCS and TMCC requirements with the compatibility of System/360 
providing the vehicle for growth. Both requirements will be addressed in 
the proposal along with the unique features and capabilities of the AMCS and 
a display-oriented checkout language now under development. 

The major problem that now exists with the preliminary design is the cost 
of the dual 44’s. We hope to overcome this by urging rental of the computing 
systems so that the budgeted dollars can be spread over many months, or 
proposing an alternate approach of using a single Model 44 with the front 
end AMCS's performing a major portion of the processing. 



JHP/mb 

cc: J. Warstler, LSG 
Attachments A-D 
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Front-End Data Handling 
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Pre-Processing 
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i Demultiplexing 

Limit Checking 

Conversion 

Parameters 
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Data Selection 

Trend Analysis 

to Range 
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TASK SUMMARY FOR CTCS PROPOSAL 



Pre-proposal Effort 

Preliminary Systems Design 

Software Design 

RPQ's 

Vendors Analysis 


Proposal Effort 
Receipt of RFP 
RFP Review 
Task Assignment 
FSD Commitment 
Strategy Review 
Competitive Analysis 
Final Systems Design 
Final Software Design 
Proposal Draft 
Evaluate Vendor Proposals 
Write Final Draft 
Systems Assurance 


FSD NBRB 
Proposal Team 
Kickoff Meeting 
Delivery Schedules 
Issue Vendor RFP's 
Receive Vendor Proposals 
Type Draft 
Management Review 
Final Type 
Reproduce 

Complex System Bid Decision 
Strategy Review Board Decision 


Preliminary Man Months 
Costing 

Final Cost Proposal 
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April 14, 1966 


ACTIVITY SUMMARY, Week Ending April 15, 1966 


TO: F. E. Mutz/ R. W. Hippe 

FROM: F, X. O'Rourke 


Item 1: Simulation requirements for the initial 2250 checkout display 

presentation have been finalized and are ready for initial flow charting 
and coding. As of April 14, 1966, actual programming has not been 
initiated. A minimum of six weeks should be allowed for coding and 
checkout after assignment of one full-time programmer (familiar with 
existing 2250 utility routines). Assuming this programming support is 
available prior to April 30, the earliest reasonable date to schedule a 
formal presentation would be the second or third week in June. 

Item 2. Presentations have been made to TMCC Air Force personnel 

(Major Hartrim, Lt. R. Smith, et al.) regarding TMCC System/operator 
interface hardware. Specific technical document have been presented 
to this group to highlight IBM's background and experience in the check¬ 
out and monitor field (referenced to the APOLLO program). It is apparent 
the TMCC group is in the process of gathering data from which they hope 
to define a general approach to the unified checkout concept. From what 
little technical information was presented by this group to IBM, it is 
apparent the effort will encounter almost insurmountable practical and 
political problems in obtaining contractor concurrence, as long as the 
concept stresses the use of a common computer facility. It was the 
writer's impression that the group is relatively weak in the computer/ 
checkout/operatcr language background, required to adequately justify 
their concept, not only to the Aerospace Corporation but also to the 
contractors who would be intimately involved in the results of this effort. 

Item 3; A general checkout discussion was held with Aerospace 

Corporation in Los Angeles on Friday, April 8, with Mr» J. O'Bell and 
Mr. Bavin. This meeting was very well received by Aerospace who 
expressed a high degree of interest in our checkout approach and stated 
it was essentially the same as their recommendations now being presented 
to TMCC personnel at Vandenberg. They were extremely interested in the 
ROS concept and expressed an active desire to further define, in 
engineering detail, hardware considerations involved in using the ROS 
as a front end "peripheral processing device" for telemetry data input. 
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Activity Summary, Week ending April 15, 1966 


Item 4: An informal discussion of the unified checkout concept 

and the 2250 display system was scheduled with Colonel Pierce SSGS 
in Los Angeles on Thursday, April 14, 1966. 

Item 5: Initial preparations have been initiated by this group to 

participate in a two-day technical seminar to selected DP sales and 
engineering personnel from the GEM Region, outlining existing technical 
requirements that must be satisfied to be responsive in this market. A 
tentative date for this seminar is the third week in May. 

Item 6: Unconfirmed data input from the OCALA project at KSC 

indicates that Martin is planning to release the initial technical guide¬ 
lines document or RFP early in May of 1966. Plans are now being made 
by this group to define the nature of the IBM response, the personnel 
who will be involved and the content of the resultant document from 
IBM. It should be noted that the issuance of an RFP either from Martin 
or Douglas would be a clear indication that the existing TMCC concept 
would probably be shelved for at least a 12- to 18-month period (if 
not longer). 

Item 7: The current unified checkout hardware specification 

document, generated by this group, is in the process of review at IBM 
Bethesda with a view to incorporating the requirements discussed in 
that document into the general RCS special hardware concept now being 
developed at SSC. It is expected that a meeting will be set up in the 
next two weeks, either at Washington or Los Angeles, to go over in some 
detail comments received from Martin Corporation, as well as Air 
Force TMCC personnel, who are presently reviewing the same document. 


F. X. O'Rourke 


FXO'R:jh 

cc: C. B. Brown ^ 

W, B, Gibson 
W. Gourlay, Jr. 
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Memo to: H. G. Hoyt, LSG 

P. A. DePascale, LSG 

R 0 K. Rea, LSG 

R. P, Bruns, GEM Region 

J. W. Richardson, GEM Region 

W, Bo Gibson, MOL 

F • E, Mutz, FSD 

Subject: Consolidated Telemetry Checkout Station (CTCS) 

at Vandenberg AFB 


Specifications for the upcoming CTCS RFP are being changed by AFWTR's 
Telemetry Group. Specifications are now calling for four telemetry 
processors, with each processor handling a single PCM link and PAM/PDM 
link. Memory cycle time is now .175 usee with considerable probability 
that this will be relaxed to 2.0 usee. Software specifications are being 
rewritten by local SDC personnel with expectation that the specifications 
will call for a system similar to the approach taken at the SCF for the 
telemetry processing. 

Expected date for release of the RFP is now May 15, 1966. Amended 
specifications are expected to be in AFWTR procurement channels by 
April 25, 1966. Fiscal year *66 money is budgeted for this procurement, 
and so considerable pressure is being put on the Range to award this 
contract by June 30. In this regard, the summary of tasks and their 
estimated completion dates outlined in my memo of April 12 should be 
held firm so as to assure maximum effort during the pre-RFP period. 

On a recent trip to FSD's Engineering Lab by F. Mutz and me verbal 
commitments by J. Nordlie, C. Hesner, and J. Deveer were obtained 
on the AMCS front end equipment in regard to technical capability, cost 
to the customer, and delivery. The functions to be performed by the 
AMCS for both the SGLS and Minuteman telemetry formats are as follows: 


1. Serial to parallel conversion 

2. Frame sync 

3. Subframe sync 

4. Code inversion 

5. LSB, MSB inversion 

6. Data compression 

7. Limit checking 

8. Standard time input 

9. Data identification 

10. Communication with either an 1800 or Model 44 
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Estimated purchase price to the customer is approximately $200,000 for 
four machines with delivery in the first quarter of 1967. Firm commitments 
from the Engineering Lab one week after receipt of RFP will have to be 
obtained in order to consider AMCS for this proposal. 

AFWTR personnel have been briefed on the AMCS with considerable 
interest obtained from the customer. It is becoming obvious that the 
AMCS is going to be one of the most important elements in winning 
CTCS. It is extremely important that Pete Davies, FSD Engineering Lab, 
visit Vandenberg for presentations to both AFWTR and the 6595th Aerospace 
Test Wing. Pete Davies is the designer of AMCS, as well as the Model 44, 
and has an extremely good presentation on the AMCS. To this date we have 
had considerable difficulty in obtaining him for this purpose'. 

Proposal rt-r-'r ;:y i *: this tire is to bid four 1800's as the primary proposal, 
and a single Model 44 as an alternate approach. This decision is based 
on discussions with AFWTR personnel, who have indicated that a single 
processor approach does not meet the design approach now considered 
mandatory by the Range, but they would be extremely interested in seeing 
this as an alternate proposal by us and would give it serious consideration. 

A meeting was held in Washington on April 15 with the following GEM 
personnel for the purpose of briefing them on the upcoming RFP: 


J. Richardson 
R. Bruns 
W. Mather 
J. Harrington 
D. Heim 
J. Kossuth 
P. Pistole 
R. Bourne 


AF Program 
AF Program 
AF Program 
Product Services 
Product Marketing 
Systems Assurance 
Commercial Analysis 
Special Equipment 


It was pointed out that due to the short response time needed by the Range 
on this proposal, normal delays in processing RPQ's, systems assurance, 
etc., will have to be kept to a minimum. It was also pointed out that our 
primary competition will come from CDC with their 1700's and that the 
1800 is not competitive in either performance or price. It was learned that 
there were plans for a 1 usee memory for the 1800, but that they had been 
dropped due to the "technical unfeasibility" of this feature. Approval of 
this feature is deemed extremely important for not only this proposal, but also 
to fill a gap in our product line for the high speed data acquisition area. 
Delivery requirements were discussed and there was general agi'eement for 
delivery of either four 1800's or a single 44 in the 1st quarter 1967 time period 


J. H. Priday 

JKP/mb 

cc: J. Warstler, LSG 
Section 3.4.1 
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by VViliard Wilks 

Vani:>cni>erg AFB, Calif. —New Air 
Force launch facility construction be¬ 
ginning this year at Western Test Range 
f\YTR) pn-sar.es a major strengthen¬ 
ing of the U.S. military space posture 
two years from now. 

By mid-1968, according to present 
schedules, initial launch capability for 
MOL will exist at WTR, where all 
manned military flights will occur be¬ 
cause of the polar orbit requirement 
(M/R, April 18, p. 14). 

Site preparation is now under way 
on the newly acquired Sudden Ranch 
property adjacent to Vandenberg AFB. 
Actual construction of the $ 18-mil¬ 
lion ILC (Initial Launch Capability) 
installation will begin soon. 

Capability expansion—Completion 
of the ILC will mean new capability 
and growth potential for other impor¬ 
tant military programs, while provid¬ 
ing for manned MOL missions. In ad¬ 
dition to the seven-segment Titan III 
configuration for MOL, the ILC will 
accommodate any other version of the 
Titan III family utilizing the 120-in. 
solid strap-ons. 

Polar-orbiting programs will be 


able to take advantage of the 25,000 
to 30,000-lb. spacecraft potential pro¬ 
vided by the Titan 1II-C family. 

“This means that any of the known 
and classified programs we have been 
launching oui of WTR will be able to 
utilize the new generation of big 
boosters and the spacecraft and payload 
growth that they permit,” an Air Force 
spokesman reported. These programs 
include communication, nuclear test 
detection and reconnaissance satellites. 

The ILC will consist of one pad 
where the vehicle will be built up on 
the pad. Although the facility’s launch 
tower will accommodate only the 120- 
in. strap-on Titan III models, including 
the full seven-segment configuration, 
the Air Force is “hedging its bet in 
the brick and mortar phase of design 
and construction to permit expansion 
to accommodate the 156-in. strap-ons 
if it decides to upgrade the booster in 
the future,” a spokesman said. 

“Long-range planning documents 
and drawings are also such that the 
ILC could at some future date be ex¬ 
panded into a complete ITL (integrate- 
transfer-launch) complex, as at Cape 
Kennedy, with multiple pads.” 

At present, Air Force plans call for 


at least five manned MOL launches from 
WTR. 

Atlas-Agena launch pad—No other 
launch construction is needed i.i the 
immediate future at WTR, the Air 
Force reports. In addition.to the Begin¬ 
ning on the ILC installation, ih one 
‘other recent improvement has beei con¬ 
version of one of the Atlas-Agenc pads 
for Titan III-D (a Titan III core with 
an Agena upper stage). The booster 
will initially be used with the Ag 'na-D 
but is also designed to handle the Tran- 
stage, Centaur and possible new vehi¬ 
cles. 

No other Atlas pad-conversions are 
planned at this time. Spokesmen report 
that the existing eight Atlas pads c.i„ 
sufficient for future SLV-3 launche 
“With the new facilities, Atlas will 
on the way out for Air Force p 
grams,” sources said. "Titan lll-C wifi 
become the new workhorse.” 

The five Thor pads at WTR also 
are sufficient and no new construction 
needed for the long-tank Thor. 

On the subject of MOL or other 
recovery plans or facilities, Air Force 
is making no official comments. It is 
almost certain, however, that water re¬ 
covery will prevail in the foreseeable 
future. 

WTR now has no responsibility for 
recovery. The organization formerly 
responsible for WTR space-payload 
recoveries, the 6594th Aerospace Test 
Wing, Sunnyvale, Calif., has been de¬ 
activated. All tracking stations and 
other facilities of the wing are now part 
of the world-wide Air Force Satellite 
Control Facility, headquartered at Air 
Force Systems Command Spac; Sys¬ 
tems Div., El Segundo, Calif. L 
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Biography of MAJOR GENERAL VINCENT G. HUSTON 


General Vincent G. Huston was born on 23 May 1914 in Norriston, 
Pennsylvania. He attended Drexel Institute of Technology, Philadelphia, 
Pennsylvania, majoring in Electrical Engineering. 

General Houston enlisted in the National Guard in January J938, 
received his second lieutenant commission in February 1938, and ' 
entered pilot training in March 1938 at Air Force Flying School, 

Kelly Field, Texas. He also attended Maintenance Engineering^ 

School, Chanute Field, Illinois, in 1939. 

Until 1943, he was given radar and electronics assignments at 
Wright Field, Ohio. From 1943 to 1945, he served in the Asiatic 
Pacific and was active in the following campaigns: Northern Solomons; 
Bismark-Archipelago; and Eastern Mandates. 

General Huston's assignments after returning to the States included 
a tour at Wright Field, Ohio, in Directorate of Procurement and Produc¬ 
tion, Headquarters, Air Materiel Command. In July 1947, he was 
named Assistant Chief, Inspection Section, Wright Field, Ohio. He 
was transferred to Aeronautical Equipment Section as Chief in Jan. 1948. 

General Huston took the Joint Operations Fourth Class at Armed Forces 
Staff College, Norfolk, Virginia from August 1948 to December 1948 
and was then assigned as Chief of Maintenance, Directorate of 
Materiel, Headquarters, Strategic Air Command, Offutt AFB, Nebraska. 

In September 1952, he was assigned as Air Force Member, Military 
Application Division, Atomic Energy Commission, Washington, D.C., 
and became Deputy Director, Military Application Division in Sept., 

1953. In September 1955, he became Deputy Director, Directorate 
of Nuclear Systems, Headquarters, Air Research and Development 
Command. 

General Huston was assigned as Commander, 3079th Aviation Depot 
Wing, Wright-Patterson AFB, with additional duty as Assistant for 
Special Weapons, Headquarters, AMC on 16 May 1957. In Feb. 1958, 
he attended the Advanced Management Program, Harvard University, 
for three months and then returned to his previous assignment. 

In July 1960, he was assigned as Commander of Air Materiel Forces, 
Pacific Area, at Tachikawa, Japan. In June 1962, General Huston was 
assigned to Headquarters, Pacific Air Forces, Hickam AFB, Hawaii, as 
Assistant Chief of Staff, Materiel. He was then assigned as Commander, 
Air Force Eastern Test Range in July 1964. On 19 July 1964, he was 
promoted to the rank of Major General. General and Mrs. Huston have 
a daughter, Patricia Frances. He is rated a command pilot. 
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B.l ETR will support MOL much the same as any other major 
program. The impact is predicted to be about twice that 
of the Gemini program. SSD will become a very large and 
important Range User, in fact, second to NASA. 

ETR's role is gradually shifting from that of Launch Support 
to On-Orbit Support. Other major on-orbit range users 
are OAR, NORAD and Foreign Technology. Support of the 
MOL Program at ETR will be similar to support of the OV 
series sponsored by OAR, except that the amount of data 
handled will be vastly greater. On-orbit support computers 
are projected for Antigua and Ascention Islands FY69. 
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C.l CURRENT STATUS 

There are no outstanding proposals that affect the MOL 
program. 

A proposal is outstanding to replace a 1410 and 1460 with 
360's, Mods. 30 and 40, at Pan American EDP. 

An order has just been received to replace two 1401's 
with a 360, Mod. 40 at USAF Technical Laboratory for 
data reduction. A second Mod. 40 is anticipated by 
March 1966. 


Section 3.4.2 


Page C/l 
2/18/66 






IBM CONFIDENTIAL 


D. PROBLEM AREAS 

The major local problem involves the Real Time Computer 
Facility with competitive equipment of two 3600's and one 
3100. The 3600’s have been accepted less than one year, 
and there is minimum Air Force interest in planning for their 
replacement at this time. IBM has the dual problem of 
preventing CDC expansion of this center and influencing 
a decision for total replacement. The Air Force is not 
now receptive to an unsolicited proposal. We need as 
much advanced information as possible on new require¬ 
ments that may help overcome this barrier. 
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E. IBM STRATEGY 


E. 1 Sales Action Program 

Local coverage is maintained for the following: 

a. NRD Detachment #1 (technical group of 180 people). 

b. Air Force Eastern Test Range and Patrick Air Force Base. 

c. Pan American World Airways, Inc., Guided Missiles 
Range Division (prime contractor). 

d. RCA Service Company-Missile Test Project (sub-contractor 
for operations and maintenance). 

e. Aerospace Corporation - Eastern Division. 

Most action centers around two major accounts: 

a. Air Force Techinical Laboratory: This is a separate 
data reduction facility. Workload is from World-wide 
sources, including Pacific Advanced Range Instrumentation 
Ships. Expansion to time-sharing for local technical 
users is planned here. 

b. Cape Kennedy Air Force Station: This is the location of the 
RTCF used for impact prediction and acquisition messages 
of all types. It is the area of concern with MOL require¬ 
ments . 


E. 2 Technical Help Required 

It is anticipated that techincal help will be needed for hardware 
interface engineering to existing equipment. This is a major 
effort that should not await an RFP. 


E.3 IBM System Design 


This is incomplete at the present time. Under investigation 
is the Mod. 67 and 9020. 
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F. SCHEDULE OF KEY TARGET DATES 

1. RFP for Weather real-time and data reduction system - 
17 January 1966 - Date of contract 1 May 1966. 

2. Cape Orbit-Support Computer and SCF interface, FY 67. 
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G. COMPETITION 

G.l Competition is virtually limited to CDC on the mainland 
and Univac downrange and on ships. 

CDC is most active with three local salesmen and 
approximately four local systems engineers. They are 
noted for giving little attention to the problem, talking 
about the 6000 series as the answer to all problems, and 
bidding minimum systems with the hope of building up. 
Their strength with Pan American has been partly lost by 
attrition and poor performance in the area of 3600 
reliability. They appear to be concentrating on NRD 
at the present time. 

Univac is represented by two salesmen locally and is 
a virtual sole source for Mil Spec downrange and 
shipboard equipment. 
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Date 


£ (Dept/Loc) 
^telephone Ext. 


January 21, 1966 
Cape Kennedy 105 



Subject: Comments on MOL Project Notebook 


Reference: 


Mr. W. B. Gibson 
MOL Program Director 
Los Angeles Aerospace 



In the latest entry to the Notebook, your letter to Mr. C. E. McKittrick, Jr. 
dated January 6, 1966, a reference is made to "our relatively weak current 
position at the Cape." We agree that the present Cape effort involves fewer 
people, but we believe the IBM strength position at the Cape has been 
underestimated. In fact, we would rate the chance of IBM winning any MOL 
connected RFP as good or better at the Cape than at West Coast locations. 
From your letter we are apprehensive that the many recipients may get an 
erroneous impression from the Cape reference. 

We are sure that our minimum inputs to date have not expressed the Cape 
position very well. We will try to improve this communication. We 
believe the MOL Project Notebook to be an excellent working tool and are 
already using it to good advantage. 

I am enclosing a copy of NRD Regulation No. 25-2 of December 14, 1965 
on the subject of range computer operations management. I am not sure 
that this regulation should be included in the Project Notebook, but is 
passed along for your information because it shows the present intent of 
NRD and the importance of coverage of the Technical Detachment at PAFB. 





i , u J w vs W'W 

A. H. Herrington 7 

AT * A JT _ T _ J? _/ / T'! 


Advisory Marketing Representative 

AHH/dlh 

Enclosure 


cc: Mr. R. P, Bruns 

AF Program 
Gem Region 
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NRDR 25-2 

NRD REGULATION HEADQUARTERS NATIONAL RANGE DIVISION 

NO. 25-2 Patrick Air Force Base, Florida 

14 December 1965 


Management Engineering 
COMPUTER OPERATIONS MANAGEMENT 

PURPOSE: This regulation establishes NRD policy on operations management of range, 
computer resources, and assigns responsibilities. 


1. Scope: This regulation applies to 
all elements of the National Range 
Division. 

2. T erms Explained . Computer resources-- 
all equipment, funds, and labor used to 
perform the range computing function. 

3. Exclusion . This regulation does not 
apply to computers procured for business 
accounting and administration under the 
provisions of AFM 171-9* 

4. Policy . NRD agencies will procure 
and operate range computers under 
waivers to AFR 300-series regulations 
and AFM 171-9* Ranges must: 

a. Assure effective use of each 
computer. 

b. Conserve computer resources. 

c. Configure all mission computers 
i and computing systems to permit rapid 

! cross-servicing between ranges and, when 
! applicable, to operate in a worldwide 
i network, 
i 

'*"■ 5- Responsibilities: 

a. Headquarters NRD will: 

(1) Monitor computer operations 
and use of computer resources, and 
coordinate between ranges. 

(2) Resolve inter-range oper¬ 
ational problems and user priority 
conflicts. 

(3) Establish inter-range 
standards for computer selection, 
operation and use, and for software 
generation, documentation and control. 


(4) Establish and publish NRD 
inter-range computer operations policies 
and procedures. 

b. NRD Ranges will: 

(1) Reduce computer operating 
overhead by consolidating similar 
tasks and overhead activities, such as 
computer programming and maintenance. 

(2) Limit the amount of test 
data reduced by establishing formal 
procedures for determining users 1 
needs before each test. 

( 3 ) Configure the real-time 
computer systems at both ranges to 
use common hardware and software : 
support inter-range operations; 

and perform all real-time or near real¬ 
time computing tasks at the range head. 

(4) Configure the data reduction 
centers at both ranges to use common 
hardware and software: permit rapid 
cross-servicing between ranges; and 
perform all data reduction, analysis, 

and scientific computational tasks. 

(5) Conduct a semiannual 
Computer Program Survey and retire 
programs which are no longer needed. 

(6) Conduct an annual Computer 
Operations Review. 

6.. Reports : 

a. Ranges will submit a semiannual 
Computer Program Survey Report to 
Headquarters NRD (NROE) by 15 February 
and 15 August each year. It will 
include: 


OPR: NROE 
DISTRIBUTION: S 
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Date: 


T rom (Dept/Loc): 



hone Ext.: 


December I, 
104 


1965 



Subject: Titan III-C Program at ETR 


Reference: 


To: W. B. Gibson 




I understand that the Martin Company has been given a contract for 
17 additional Titan III-C standard launch vehicles. These will be 
boosters for payloads which as yet have not been specified. The 
current R and D program for the Titan III-C is also for 17 boosters 
with all of the remaining ones having an active payload. Vehicles 

II and 12 will carry Philco payloads and 13 will have a Philco and 
G. E. payload combined. 

This extension of the ITL facility utilization is considered by some 
Martin Company Cape people as justification for up-grading their 
GSE for improved launch control and to offer a service for payload 
checkout. The results of the OCALA Study Project will have a 
strong bearing on their ability to sell this concept. 

I believe that the Air Force will be so dependent on the OCALA system 
by next June that they will continue it as an operational system until 
a replacement system can be procured. IBM must be ready to propose 
a replacement system around April. 1966 . It will probably have to 
be installed in late 1966 to avoid a competitive procurement. The 
ETR and WTR systems need not be alike, in my opinion, but it would 
be desirable if they could be. I believe this will depend on the extent 
to which the WTR system replaces the present GSE used on the Titan 
III. 


Your assistance on getting an 
appreciated. 

REB/cfc 


arly delivery schedule would be 



cc: W. O. Robeson 
R. W. Swanson 
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Launch/Recovery Facilities 







inches 


by Kurt Voss 

Patrick AFB, Fla. —The Eastern Test 
Range will probably not undergo any 
major changes in its launch facilities 
in the foreseeable future. 

Col. O. C. Ledford, commander of 
the 6555th Aerospace Test Wing, 
which has jurisdiction over Air Force 
launch activities at ETR, says: “We 
have the core of the facilities we re¬ 
quire here for military space work. The 
Titan III is the vehicle to provide 
military space developmental capa¬ 
bility.” 

He sees the Titan III as “the DC-3 
of the military space program,” and 
predicts that all developments in the 
immediate future will be based on 
adaptations of the liquid/solid vehicle. 

The only major facilities modifica-. 
tions he sees would be those required 
by use of a seven-segment Titan III 
booster configuration, instead of the 
five-segment solid strap-ons now used. 
The switch to the longer booster 
would require modifications of the 
launch pad flame bucket, the Titan 
transporter undercarriage, and heavy 
cranes in the solid-motor assembly 
building. 

Expanded 1TL not seen—Though 
the Titan III integrate-transfer-launch 
complex (ITL) at Cape Kennedy could 
probably be expanded to handle the 
seven-segment version of the booster, 
the Air Force thus far has not identi¬ 
fied any missions to be flown from ETR 
which would require this. 

High-ranking Air Force officers also 
admit that the ITL at the Cape would not 
be readily expandible to handle the 
156-in, solid motor strap-on if a mis¬ 
sion develops for that vehicle. 

The Air Force is preparing a 
follow-on production plan for addi¬ 
tional five-segment Titan III-C vehicles 
(M/R, April 18, p. 14), in addition to 
the 10 remaining R&D vehicles. The 
new vehicles will be used to launch 
replenishment payloads from ETR for 
the Initial Defense Communications 
Satellite Program (IDCSP), for nuclear 
detection satellites and probably for 
some new multiple engineering pay- 
loads from ETR. In addition, the Titan 


III-C will probably be required for loft¬ 
ing communications satellites associ¬ 
ated with both follow-on strategic and 
tactical comsat systems (M/R, Jan. 31, 
p. 46). 

Launch officers here also foresee no 
changes in command and control facili¬ 
ties outside of the switch in telemetry 
and command radio frequencies now 
going into effect. “We have a capability 
here now that far exceeds our present 
work load,” they have reported. 

New recovery concept—At nearby 
Orlando AFB, the Air Force’s Aero¬ 
space Rescue and Recovery Service 
(ARRS) has come up with a new heli¬ 
copter/ in-flight refueling team concept 
for water recovery which could go a 
long way toward taking some of the 
strain off the Navy’s recovery fleet. 

The operation is especially appeal¬ 
ing as planning for the Manned Orbit¬ 
ing Laboratory program gets under 
way. 

With MOL crews orbiting for 30-day 
missions, the requirement to be pre¬ 
pared for sudden mission aborts could 
tie up a substantial number of Navy 
ships on an almost permanent basis. 
This is a real and troublesome problem 
at this point. 

Using the new helicopter/fixed wing 
refueling aircraft team, ARRS officers 
point out that recovery squadrons 
posted at key spots around the world 
would allow MOL/Gemini-B space¬ 
craft to be picked up by crews which 
were continually on alert but which 
did not have to be on station. 

“For the first time,” says Col. 
Bestow R. Rudolph, deputy chief of 
plans at ARRS headquarters, “we will 
have a true rescue capability as of the 
end of this year, even with no support 
ships in a given area.” 

At present, ARRS has 30 four- 
engine C-130’s and 10 Sikorsky HH3E 
helicopters available for its worldwide 
rescue work. It has been authorized a 
total of 54, plus backups, in its stock 
of C-130’s, and a total of 24 of the 
140-knot helicopter. 

Aircraft-helicopter team—Using the 
team concept, the C-I30’s double as 
rescue aircraft, which carry and drop 
pararescue teams, and as flying tankers. 
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which carry large loads of fuel for the 
FIH3E helicopters. 

The newly developed system of in¬ 
flight refueling gives the HI13E’s an 
almost unlimited range, and their speed 
is enough to shift areas of coverage 
quickly to follow changing orbits. 

Should a landing footprint change, 
the refuelablc capability will allow the 
helicopters to change position immedi¬ 
ately without the need to return to land 
or a ship, either of which could be 
hours away. 

Even larger helicopters—the Si¬ 
korsky HH53A—have been ordered. 
These craft are large enough to pick up 
the entire Apollo space ship from the 
water and carry it long distances, with 
the crew still inside, if necessary. 

Col. Rudolph predicts that in the 
near future these larger helicopters will 
be the prime recovery vehicles, with 
the Navy doing the support of a pickup 
mission—just the opposite of today’s 
recovery modes. 

Delivery of the new units will start 
in August when two CH53A’s, cargo 
helicopters converted to search and res¬ 
cue equipment, will arrive at Patrick. 
Rescue capabilities with the new craft 
will start small and grow as equipment 
funding becomes available. 

The HH53A’s will be equipped to 
use the team concept, with refueling 
capabilities even when carrying full 
loads. 

Emergency rescue—Another new 
concept, just publicly demonstrated, 
also is in ARRS plans for emergency 
recovery use. The first week in May 
marked the public testing of the Fulton 
pickup system, by means of which a 
downed astronaut can be snatched from 
water or dry land by a C-130, or similar 
plane, even if weather keeps helicopters 
away. 

Using the system, the downed flyer 
dons a special suit-like harness. He in¬ 
flates a polyethlene balloon with helium 
gas. This balloon lifts a 500-ft. nylon 
line into the air, one end tied to the 
harness and the other held aloft for 
pickup by the plane. 

As the aircraft approaches, its pilot 
lines up a V-shaped guide on the plane's 
nose with the line and flies into it. As 
the line strikes, a small arm in the apex 
of the V suddenly twists, locking the 
line securely The cable is pulled back 
by the airstream against the pla.ne’s 
underside, where it is grabbed at the 
rear of the fuselage and hooked onto a 
winch. 

G-forces on the man being picked 
up are said to be less than those experi¬ 
enced in a normal parachute jump and 
much less than those of previous pickup 
systems. 

The entire pickup kit—harness, bal¬ 
loons, gas supply, and nylon line-—is 
dropped by the pickup plane. □ 
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A. 1 PERSONNEL PROFILE 


a) Col. Robert Gould - Flight Test Center Comptroller believes 
strongly in central management of data processing equipment. 
Frequently "Bumps Heads" with scientific side of house. 

b) Mr. Ralph Western - Chief, Data Systems and Statistics Branch. 
Data Processing Equipment Control Officer for the Flight Test 
Center. Reviews and exercises approval authority on all Center 
initiated requests for digital data processing equipment. 

c) Mr. Alfred Phillips - Chief, Directorate for Technical Support. 
Heads entire plethora of ground based technical support for all 
flight test programs. 

d) Mr. Alfred Miller - Chief, Data Systems Division. ( Mr. Harold 
Knausdorf - Acting during one years leave of absence by Miller). 
Responsible for Acquisition, Reduction, Processing and Analysis 
of Scientific Type Flight Test Data. 

e) Mr. Charles Kroll - Chief, Requirements Analysis Division. 
Responsible for coordination with all other divisions in the 
definition of requirements for future flight test projects. 

f) Major Harold Smith - Chief, Data Systems Engineering Division. 
Responsible for all non-standard special purpose data systems 
connected with flight test projects. 

g) Col. Charles Yeager - Commandant, Aerospace Research Pilot 
School. Responsible for advanced flight training and technical 
classroom training for all Air Force Astronauts and Experimental 
Test Pilots. 
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B. BACKGROUND 


B. 1 The Air Force Flight Test Center has the mission of performing 
initial evaluation on all winged, lifting body, and rotary type 
aircraft that might enter the Air Force inventory* Prior to 
project cancellation in early 1964, the Flight Test Center was 
designated as primary recovery site for the X-20 Dynasoar 
Vehicle. Current role in MOL is restricted to crew training 
at the Pilot School. Unless land recovered Shuttle Vehicles 
are to be utilized, Flight Test Center Personnel see no direct 
mission in support of MOL. 

B. 2 Equipment installed at FTC includes: 

a) 7094/7044 Direct Couple System including a 7288 Real-Time 
Interface with the Edwards Range. 

b) 1410 File oriented system for commercial type data processing. 

c) 1620 - 40K System for use by Flight Test Engineers as 
"Quick-Look" machine. 
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C. CURRENT STATUS 


C. 1 The Flight Test Center is one of the four accounts involved 
in the recent Air Force Multiple Replacement Program 
(IBM Name: Project FORCE) along with: Systems Engineering 
Group (SEG), Wright-Patterson AFB, Ohio; Air Proving 
Ground Center (APGC) Eglin AFB Florida; and Ballistic 
Systems Division (BSD), Norton AFB California. 

IBM submitted a ’’Technical Information Document" and a 
No-Bid due to inability to meet Air Force Demonstration 
requirements. The Air Force has since decided that no 
EDP Manufacturer was responsive and present information 
indicates a repetition of the exercise in second quarter 66. 
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July 5, 1966 


To: Mr. W e 8. Gibson 

Frank Bales 

Subject: Edwards Air Force Base - MOL Participation 


Lt. John Prodan, Chief of the simulation Division, Aerospace 
Research Pilot School, today told me that the Simulators for MOL 
will be located at Huntington Beach and at Vandenburg. He said 
that the only mission that Edwards will have, at least at present, 
will be in the first phase of training. 

/s/ 

Bob Glascock 
BG:md 

cc: Dale Edwards 
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CUSTOMER NAME: Aerospace Medical Division 

Brooks Air Force Base 
San Antonio, Texas 
Phone: 512/532-8811 


REGION: 


DISTRICT: 


BRANCH: 


BRANCH MANAGER: 


ACCT. MANAGER: 


DP SALESMAN: 


FSD REPRESENTATIVES: 


Western 


14 


San Antonio 


J. R. McSween 


J. R. McSween 


Pat Graham 


Bill McLain 


OTHER IBM PERSONNEL: Tom Johnson, Federal Rep. ,San Antonio 

Bob Vesper, CE, San Antonio 
Charlie Brown, MOL Proj.Office, LA 
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IBM CONFIDENTIAL 


B.l Backgrounds 

Dr. Danford - Biometrics Branch Chief 

Neutral to negative on IBM hardware; likes his Philco 2000. 

Has turned down an attempt to present our 360 presentations. 

PhD in Statistics — no modern concepts applications 
orientation — L.P., CPM, GPSS, Etc. 

Has turned down numerous attempts to enroll in IBM 
schools. 

Very hard nut to crack. 

Does like some of IBM’s work in med. application area. 

Seems open to an approach on communication aspects of 
MOL, but suggests a contract study (Lockheed). 

Dr. Hughs 

No data; passes all calls to Dr. Danford. 

Mr. Bob Bales - Computer Ops Chief 

Good automation man. Would like to work with us, but 
he is #3 and has no decision authority. 

All three men were very heavily involved in medical data reduction 
on all astronauts up to the present time. They will probably fill 
the same function on a now real time basis, in the MOL program. 

Mr. Adams - Environmental Br. 

Interested in development and utilization of medical data 
sensory devices on board the vehicle, provide data to 
Dr. Danford via telemetry and a communication capability 
into SAM. 

B.2 IBM has keypunch and unit record installed. 
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Date 

From (Dept/Loc) 


December 27, 1965 
San Antonio 390 


„ Telephone Ext. 

c _ 


Subject: 



Reference: 


To: Mr. W. B. Gibson 
MOL Project Director 
Western Region 

I spent approximately an hour with Lt. Colonel Stan White, AMD, Brooks Air 
Force Base, last Friday morning. Results: 

1. He is going to Washington this summer to act as the AMD Coordinator 
with the Headquarters AFSC MOL Project office. He will be in the same 
position there as Colonel Carstairs is in, in California. 

2. LTC Ord, AMD, will be MOL Project Coordinator at AMD, Brooks Air 
Force Base. 




3. AMD's tasks under the MOL Project will include: 

a. Personnel selection. 

b. On long term-days-manned flights, they will provide a near 
real-time, bio-medical data reduction capability. 

c. Analysis of occurrences to/or by humans, during and after flights 
to provide input for decision concerning personnel selection, flight 
duration, man or machine job/experiment mix. 

4. LTC White may attend EX-34 in San Jose, January 31 through February 4, 
1966. 

Dr. Danford, Biometrics Chief, has turned down invitations to attend SC-78 and 
EX-34. Feels he knows enough now to evaluate his needs. Present equipment 
consists of Philco 2000, 4K mainframe, 8 tape drives, A to D to A converter for 
interface with PACE 3000 Analog Computer, IBM keypunch 407-519. 

Pat Graham 

Federal Marketing Representative 
PG:al 
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SAN ANTONIO 390 


April 4, 1966 


TO: Mr. Charlie Brown 

MOL Project Office 
9045 Lincoln Boulevard 
Los Angeles, California 90045 


Here is a write-up on some of the activities at AMD for your interest. 
Of more immediate importance for our notice is the situation concern¬ 
ing Dr. Danford's Philco 2000. I think a decision has been made to 
replace it with a whole new package; and, as soon as we and 
Univac finish our proposals and a selection is made, they will 
go in for new equipment. I have not been able to dent Dr. Danford, 
Dr. Hughes, or Mr. Bales at all, but we keep trying. The write¬ 
up of the Altac/Tac to FORTRAN Il/FAP translators in the December 
ACM Journal may help us when they bring up the conversion problems 
again, as they no doubt will. Dr. Danford's feeling has been for 
a long time that, aside from being very satisfied with their system, 
they were locked in by their software inventory; and this conversion 
capability may be a way in for us. I'll keep you posted. 


Pat Graham 
PG:al 
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Bends Posing Difficult 
Problems in Space Science 


By JERRY LOCHBAUM 

The threat of space bends is posing difficult problems for 
Air Force scientists seeking ways to protect space-walking 
crewmen of future orbiting laboratories against this danger¬ 
ous low-pressure ailment. 

Extent of the problem of the bends—caused by the 
bubbling of dissolved gases when pressure on the body is 
lowered—is reflected in these new developments at the 
School of Aerospace Medicine at Brooks AFB: 

• A team of researchers has just completed a lengthy 
series of tests and is preparing to report formally that helium, 
breathed with oxygen instead of the nitrogen of ordinary 
air. has failed to provide bends protection some authorities 
had predicted. 

• In the tests, about one man in five got bends in 206 
manflights simulating Air Force Manned Orbiting Laboratory 
(MOL) missions. Bends occurred in simulated space suit 
work outside the MOL. 

• A new series of tests has begun in which men who 
get bends in lower-pressure space suit conditions are treated 
in higher-pressure spaceship cabin conditions, to determine 
time lapse necessary between extra-vehicular activity (EVA) 
excursions into space. 

• The idea is emerging that an orbiting laboratory 
cabin pressure higher than that in present spaceships would 
be desirable, to permit a space walker in trouble to use his 
own ship as an emergency recompression chamber capable, 
with his space suit, of returning him to ground pressure. 

• Frequency of bends after exposure to possible future 
two-gas spaceship atmospheres causes some to think the SAM 
studies could lead to making bends-susceptibility a criterion 
for space crew selection. 

BENDS HAVE been a traditional problem of deep-sea 
divers, who face lower pressures on the body when they 
come up. The bubbling of the gases in the blood can cause 
much pain and possibly disable the bends sufferer, and it can 
be fatal. 

The bends problem is not regarded as a serious one for 
today’s space-walking astronauts, who breathe pure oxygen. 
The nitrogen portion of air is principally blamed for caus¬ 
ing bends. 

While pure oxygen has been proven safe for use up to 
30 days, it can have dangerous effects and space scientists 
have been looking for a better kind of mixed-gas atmosphere. 

Nitrogen-oxygen and helium-oxygen appeared to be the 
most likely .prospects. Helium’s promises of offering less risk 
of the bends, because of its lower solubility in the body, was 
one principal reason for its selection for thorough evaluation 
in SAM studies which began in November. 1964. 

SAM researchers had begun studies of nitrogen-oxygen 
bends risks in early 1964. They later expanded their program 
to compare helium-oxygen effects. 

MAJ. SARAH E. BEARD, a key figure in the bends 
studies, said especially qualified volunteers in space cham¬ 
bers were put through pressure changes which might be met 
on an MOL mission with EVA, in paired flights carefully 
controlled so nitrogen vs. helium comparisons would be pre¬ 
cise. 

Time of bends danger came after leaving simulated MOL 
conditions—half sea-level pressure in two types of flights and 
one-third that pressure in another—to go to space suit 
pressure one-fifth that at sea level. 


“Decompression following exposure to helium-oxygen,” 
said Maj. Beard and her co-workers, “generally caused an 
equal or greater number of cases of bends in varying grades 
of pain than did exposure to nitrogen-oxygen.” 

While helium has been found faster than nitrogen both in 
entering and leaving solution in the body, the researchers 
said from comparison of effects it “appears that, once pre¬ 
cipitated, ‘nitrogen bends’ and ‘helium bends’ are similar ...” 

Others on the bends study team were Dr. T H Alien 
head of SAM’s physiology branch, Dr. (Lt. Col.) R. G Me-’ 
Iver, and Dr. R. W. Bancroft. 


^ THE simulated flights—compared to normal, 
ground-level atmospheric conditions of 20 per cent oxygen, 




_ ' . " vi wiki, gnovn. <xi jnoi 

square inch (psi) pressure-were: ' 

• Four hours breathing pure oxygen at ground pres¬ 
sure, to wash nitrogen out of the system. 8 P 

• tu Two anc * a hours breathing pure oxvgen at five 
P?J U.S.. spaceship atmosphere, to simulate a 

orbiting MOL 6 ””” 1 capsule t() rendezvous and dock with an 


• In one of the three flight patterns, 15 minutes of pure 
oxygen at 3.5 psi, the environment of U.S. space suits. This 
phase, with knee-bends and push-ups to simulate exertion in 
space, represented transferring from the Gemini to the MOL. 
Other flights skipped this phase, evidently assuming possi¬ 
bility of direct entry as through a proposed Gemini heat 
shield tunnel. 

• Four hours simulating a shirt-sleeves stay in the MOL. 
In two flights, atmosphere was about half oxygen and half 
nitrogen at seven psi. In the third, it. was a mixture of about 
70 per cent oxygen-30 per cent helium at five psi. 

• Two hours of work EVA, breathing pure oxygen again 
at 3.5 psi as in a space suit, and doing exercises periodically. 

In all, out of 206 man-flights, 39 cases of bends were re¬ 
corded in the work EVA phase. In contrast, only four cases 
of bends in 70 man-flights were recorded in the double-EVA 
tests’ first space-suit stage, preceded by long denitrogenation. 


ADDITIONAL FLIGHTS tested effects of pre-breathing 
pure oxygen for half an hour in the MOL to wash out pos¬ 
sible bends-producing gases before the work EVA phase. 

“There is only a marginal benefit from oxygen pre-breath¬ 
ing,” Maj. Beard said. She would like to study this aspect 
of the problem further, testing effects of a full hour’s 
oxygen pre-breathing. 

As expected, the researchers said, there were fewer 
cases of bends in going to the work EVA stage from the 
five psi tentative MOL atmosphere than in the greater change 
from the seven psi atmosphere. 

In the continuing debate over which atmosphere the MOL 
should have, this might be counted a point for sticking 
to the present low-pressure level. But there is another con¬ 
sideration, Maj. Beard pointed out. 

Men who developed bends in the tests were treated by 
driving the bubbling gas back into solution through return 
to higher pressure, and use of pure oxygen. A special cham¬ 
ber capable of high pressure treatment is kept ready nearby, 
she said, but it has not been needed. 

“We have had some men who have required ground- 
level (pressure) plus time for bends recovery,” she empha¬ 
sized. 
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Bends Posing 
Space Problem 

This leads to an observation not part of the researchers’ 
formal report to be presented to Aerospace Medical Associa¬ 
tion at Las Vegas, Nev., in April, an opinion taking shape 
with experience: 

“Medically, we would like to see, for the sake of the 
man who gets bends, a seven-psi ship . . Maj. Beard said. 

SPACE SUITS, normally kept at 3.5 psi because balloon¬ 
ing and stiffening effects of higher pressure make use awk¬ 
ward, can in an emergency be inflated to seven-psi pressure, 
she explained. 

That pressure, with seven-psi cabin pressure added, could 
return a spaceman with the bends practically to ground-level 
pressure, which some have needed. 

The researchers made no recommendations either on 
helium use or on MOL atmosphere in general. They are 
moving on with their work. There is a lot to be done before 
the first scheduled manned MOL mission in 1968. 

In a new test series begun last Tuesday, men are breath¬ 
ing oxygen for an hour and a half and going directly to 
space-suit conditions for varying periods, with exercise. 

Those who get bends are brought to five psi for treat¬ 
ment. This pressure, plus normal space suit pressure, brings 
them “down” from equivalent of 34,500 feet to 14,000 feet 
altitude. 

The question, said Maj. Beard, is this: “How long must 
a man stay in the laboratory under treatment before he can 
succ essfull y go out into space again?” 



SPACE-WALK PUZZLE— When Astronaut Edward 
White took .his famed space walk last June, he 
breathed pure oxygen in the spaceship and in his 
suit. If future spaceships go to a different atmos¬ 
phere of either nitrogen-oxygen or helium-oxygen, 
how much risk of bends would space walkers run? 
School of Aerospace Medicine researchers are find¬ 
ing that a troublesome question to answer. 
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SPACE MEDICINE 

AF Completes 70-Day Inactivity Study 

The Air Force has concluded a 70-day experiment on 
the effects of inactivity using five volunteer subjects with 
age, training and experience qualifications similar to those 
of astronauts. The men were confined to complete bedrest 
for six weeks, during which blood test* were taken daily 
to study blood cell formation and rate of red-cell destruc¬ 
tion under inactivity conditions. Calcium studies alsc were 
conducted. Results are now being analyzed. 

Animals Survive 236 Days in li00% Oxygen 

Experiments at the Aerospace Medical Research Labora¬ 
tories’ Toxic Hazards Division indicate that survival under 
long-term exposure to a pure oxygen atmosphere at reduced 
pressure of 5 psi is indeed possible. More than 100 animals 
—including mice, rats, dogs and monkeys—spent 236 days 
in an altitude chamber and showed normal results from 
blood-count and chemistry tests. Although 11 rodents died 
during the time, the survival rate was better than irf the 
control group, and was not considered unusual in long-term 
experiments with such animals. 

AF Reports on Confinement Tests 

The Air Force’s Aerospace Medical Research Labora¬ 
tories reports that there seem to be no problems with pro¬ 
longed periods of restricted human physical activity, pro¬ 
vided sufficient exercise is available to maintain metabolic 
efficiency. In a recent series of tests, three groups of four 
men each were confined for 28 consecutive days, exercising 
regularly on a bicycle ergometer. In general, the prolonged 
confinement caused no significant measurable physiological 
changes from control values recorded before the test, the 
Air Force asserted. 

SAM Produces Space Dental Kit 

A dental repair kit for astronaut use is being tes ed by 
the Air Force School of Aerospace Medicine in a 12-day 
simulation chamber training test. Developed under the direc¬ 
tion of SAM’s Dr. James Hartley, the 1.3-lb. kit is being 
proposed for possible use in orbital spaceflights of long 
duration. Dental troubles such as a gum infection, trench 
mouth and a filling break delayed three ehamber simulations 
at SAM, provoking the research. The kit includes forceps to 
pull teeth, local anesthetic and filling material to permit one 
astronaut to perform emergency dental work upon the other. 


missiles and rockets, April 18, 1966 
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Life Support 
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Dr extravehicular 


•erariosis 


by Heather M. David 

Washington —The Air Force has con¬ 
tracted with the David Clark Co. for 
Gemini extravehicular spacesuits, which 
apparently will be the basic uniform for 
manned operations in the immediate 
future. 

The Air Force, however, although 
it has released no details on modifica¬ 
tions, has indicated it would like to 
have a better thermal protection system, 
as well as less bulky garments, to pro¬ 
tect against micrometeorites and radia¬ 
tion. 

A number of in-house efforts are in 
progress at Brooks AFB, Tex., (M/R, 
April 25, p. 39) on new concepts of 
cooling and pressurization which might 


afford better mobility, and a study of 
the entire field is being put together 
with recommendations for the future 
by a contractor for the Aerospace 
Medical Research Laboratories. 

For the time being, however, offi¬ 
cials say the Gemini suit appears well 
fitted for some of the repair and rescue 
and extravehicular experiments the Air 
Force has in mind. At present there is 
no specific interest in a hard suit such 
as that being developed for NASA by 
Litton Industries, since the Air Force 
has no mission to land on the Moon 
or another planet. 

The Air Force is still wrestling with 
the knotty problem of which combina¬ 
tion of atmospheric gases to use in the 
Manned Orbiting Laboratory. . 


A decision on an oxygen/helium 
atmosphere at 5 psi was nearly firm 
some months ago, but a series of several 
hundred experiments on decompression 
from this atmosphere to the pure-oxy- 
gen, 3.5-psi atmosphere which would 
be used in spacesuit operation has 
muddied the picture considerably. 

These experiments, carried out at 
the School of Aerospace Medicine by 
Dr. Thomas Allen and WAF Maj. Sarah 
Beard, showed that the decompression 
from helium/oxygen produced even a 
greater number of bends than did the 
same pressure-drop ratios from nitro¬ 
gen/oxygen. However, in spite of the 
new evaluation of the bends problem, 
little thought is being given to sticking 
with the pure-oxygen atmosphere used 
by NASA for the Gemini program. 

The environmental control system 
contract with Hamilton-Standard Div. 
of United Aircraft includes evaluation 
of both nitrogen and helium as a 
diluent. 

Regenerative systems—While the 
Air Force has been a leader in develop¬ 
ment of regenerative subsystems for 
life support in space, the day when 
such a method actually will be used 
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apparently is far distant. 

Present, thinking is in favor of the 
resupply of oxygen and other necessi¬ 
ties in orbit, rather than regeneration 
from wastes in a closed-cycle system. 
Systems currently in design could pro¬ 
vide subsistence for 60 days without 
resupply, Air Force officials feel. 

Should a mission have to go six 
months in orbit without resupply, they 
feel a tradeoff point might be reached 
at which a regenerative system should 
be installed. A number of companies 
are working on study contracts for 
various aspects of regenerative systems. 

Trace-contaminant control—The 
materials and trace-contaminant labora¬ 
tories located at Wright-Patterson AFB, 
Ohio, will, be the center of evaluation of 
materials for use in Air Force vehicles. 

Here, in closed chambers called 
“Thomas Domes’’ after their designer. 
Dr. Anthony Thomas, materials and 
subsystems can be run at various pres¬ 
sures and in various atmospheric mix¬ 
tures to determine their exact outgassing 
properties and possible contamination 
problems. 

While catalytic burners have been 
suggested for Earth-orbital missions, the 
Air Force reports that no decision has 
yet been made on trace-contaminant 
control, although the problem is recog¬ 
nized and a positive approach will be 
taken. 

Biomedical monitoring—While the 
Air Force philosophy generally favors 
minimal monitoring, some physiologi¬ 
cal research monitoring is expected 
when longer in-orbit times are achieved. 

The Air Force is most interested in 
monitoring devices which will be the 
least restrictive and annoying to the 
space crew, such as the incorporation 
of electrodes into helmets and. other 
gear. 

The AMRL labs at. Wright-Patterson 
are developing a cigarette-package-sized 
electrocardiogram monitor, and other 
work on microminiaturization is going 
on at Holloman AFB, N.M., and 
Brooks AFB. 

Parameters expected to be measured 
include the standard physiological 
measurements such as electrocardio¬ 
gram, electroencephalogram, respira¬ 
tion, pulse and galvanic skin response. 

Also being examined is the question 
of biomedical research in the longer 
missions, including the possibility of 
chemical analysis of body fluids in orbit. 

While the NASA/DOD agreement 
on the Biosaiellite largely rules out any 
experiments on large animals in Air 
Force Earth-orbital missions, it is very 
likely that some biologic experiments 
will be carried, depending upon the 
state of the art of such experiments and 
the nature of each mission. 

Restraint systems—Current plans 
arc for MOL astronauts to sleep in 



Pre-test checkout of "iron pants” thermal outer garment developed by . 
Materials Laboratory at Wright-Patterson AFB. Suit is designed to protect 
from 1,200°F gas plumes of the Astronaut Maneuvering Unit’s jet thrustei 
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n i*sck- iiki dc. icos while in orbit, 
alihough i.o testing of such devices has 
yet been done in weightlessness. 

Restraint at the work area is ex¬ 
pected to be provided by toe holds and 
hip restrainers, and various strap de¬ 
vices also are being looked at. The 
standard Gemini couch will be used 
during re-entry. 

Future research—The Air Force is 
stepping up its ef'oits in a number of 
areas in support of space missions 
throughout its Aerospace Medical Divi¬ 
sion. 

The basic problems of weightless¬ 
ness—studied through bedrest and im¬ 
mersion—continue to be of prime 
importance at the School of Aerospace 
Medicine at Brooks AFB. 

Work on decompression, as well as 
sophisticated psychological and psycho¬ 
metric studies, is being carried out 
with chimpanzees at the Aerospace 
Medical B esearch Laboratory at Hollo¬ 
man AFB. , 

New emphasis is being put on re¬ 
search on the effects of various areas 
of the electromagnetic spectrum. While 
some aspects are classified, it is known 
that the Air Force is considering use 
of advanced electro-optical sensors 
aboard MOL, -and may also be con¬ 
sidering test of a new thermoelectric 
radioisotope unit under development 
for the ABC for eventual power supply 
purposes. 

Research on radiation and radiation 
protection by pharmocological means, 
shielding and the like, also is receiving 
emphasis and will be greatly enhanced 
with the completion of a new bionucle¬ 
onics laboratory at the School of Aero¬ 
space Medicine at Brooks (M/R, Nov. 
15, p. 34). 

Other research areas of prime im¬ 
portance, AF officials say, are long- 
range psychological studies on man, the 
effect of diurnal cycles and lack of an 
Earth day-night reference on man’s 
ability to work efficiently, and nutrition 
problems. 

Also one of the most important 
problems, top officials say, is that of 
waste disposal. What the Air Force 
would really like to see, officials say, is 
a disposal unit as big as a cigarette pack¬ 
age which would obviate the storing of 
waste material on long-term missions. 

Expansion—While the diversion of 
funding to Vietnam is affecting the rate 
of expansion of the Aerospace Medical 
Division, some new facilities are being 
planned in support of current programs. 

One under way is a new impact 
facility at Wright-Patterson AFB. It 
will permit more precise duplication of 
the exact vibratory stresses which crew¬ 
men will undergo in flight, both 
from booster engine and aerodynamic 
sources.. Q 

n; Lf.es and rockets. May 30, 1966 
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IBM CONFIDENTIAL 


MOL STANDARDIZED CALL/TRIP REPORT 

Customer/Prospect Name (1) Space Systems Division _ 

Individual(s) contacted (16) Colonel A.I. Karstens. Asst for Bioastronautics 

and Aerospace Medicine, AMD 

Your Name (60) C. B, Brown _(70) Date (71)_ 6/2/66 _ 

Summary of Facts Covered: 

Purpose of the trip was to explore bio-med requirements for MOL. Colonel 
Karstens was very warm and friendly as opposed to the previous call two 
months ago. We covered IBM's interest in the medical field and reviewed 
some of the programs that IBM had worked on in the past. I informed him that 
we were organizing some presentations for Dr. Danford of AMD, San Antonio, 
when he visits Los Angeles in July. I asked Colonel Karstens if he could be 
available to attend these presentations also. He agreed that he would be most 
interested and was particularly interested in a 2250 demonstration at the same 
time. 

He asked me to write a letter outlining in some detail the presentations we 
wanted him to hear and the approximate date they would be made. I will send 
him this letter the week of June 6. 

Colonel Karstens stated that they are more interested in the environmental 
conditions of the laboratory than the man, himself, in the MOL program. He 
said that if the laboratory conditions were within the limits established for 
the safety and well-being of the astronaut, they could be reasonably sure the 
astronaut, himself, was okay. 

I have covered this call with Paul Tobias and asked his cooperation in helping 
us get together our presentation for Dr. Danford and Colonel Karstens. We 
plan to establish the agenda for the presentations the week of June 6. 


C. B. Brown 


CBB/lr 

cc: Mr. H. G. Botard, GEM Region 
Mr. W. B. Gibson, Local 
Mr. J. P. Jones, FSD 
Mr. J. R. McSween, San Antonio 
Dr. B. W. Randolph, FSD 
Dr. P« R. Tobias, FSD 
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IBM CONFIDENTIAL 


Eglin Air Force Base 

Eglin Air Force Base, Florida 

Area Code 904/No. 881-6668 


Midwestern 


21 


Mobile 


W. C. Stiefel 


J. H. Jones, Jr. 


J. R. Kerr 
R. E. Ballow 
G. D. Yates 


None 


K. G. Saley, FE Field Mgr. 
10 Customer Engineers 
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IBM CONFIDENTIAL 


A. 1 Personnel Profile 


Major General James E. Roberts - Center Commander 


Not impressed by - not interested in data processing. 
One invitation to an ECC class has been given. He 
could not attend at the time. 

Not a technical man - his former deputy was and he left 
after some conflicts on policy. 


Colonel Fred Moore 


Twenty-one or twenty-two years in grade as a full colonel. 
Good tennis player, musician, ham operator, and compet¬ 
itive race car driver. 


Chief of Engineering Directorate 

Now vacant - William McGraw was in this position before 
moving to location on the west coast. 


VITRO Corporation operates the range facilities for this 
directorate. They operate radars, theodolites, commun¬ 
ications and telemetry stations. 
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B. Background 


B. 1 One of the radar stations serves as the range control 

center at Eglin and is also the Tracking Station 17 of 
the manned-space projects. This station performs the 
same as any of the other mandatory tracking stations 
in the international tie-in. 

Located at the station are four FPS-16 radars. At least 
one, and I suspect more than one, of these FPS-16 has 
the most recent power modifications to increase the range 
significantly. 

During a manned space shot, the data control computer 
at Eglin is not on line at all. 

The range facilities at Eglin are tied to the data control 
computer. We can accept data in real-time from most 
of the range radars and a 60 ft. tracking telemetry disk. 
We can also pre-position range radars and control radar 
searches by use of our 7094II. 
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B. 2 IBM Equipment 

Data Control 


7094 II 


2 Channel 
18 tape - 729IV 
Card Reader 
Printer (with clock) 

Sage Mode 

DDC - The DDC interfaces with some 16 equipments 
built by other manufacturers. The interface 
is through a passive multichannel switching 
system built by Milgo. 

2 Printer 1401 


1 - 1402 

2 - 1403 - 600 LPM 
4 - tapes 

8 K 


1 Printer 1401 
4K 

3 - tapes 

1 - 1403 - 600 LPM 
1 - 1402 

2nd 7094II due in first quarter of 1966 


2 Channel 
8 tape 

Card Reader 
Printer (with clock) 


Utilization of the installed 7094II for the month of 
November was 602 clock hours. Have approximately 
3, 000 hours of backlog. 

This entire facility will come out for bid in April, 1966. 
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Also installed at Eglin: 

1410 T/R system with 1301 and TP for management 
applications. 

On order to be installed at Eglin: 

AFWET - Air Force Weapons Effectiveness Test 


Real time testing of up to 16 airborne and 10 ground 
weapon systems with the computer determining n hits" 
and notifying all concerned of "hit" targets. Joint 
effort with Raytheon, Hayes Aircraft and Vitro. 

IBM Equipment - 

2065 
2860-3 
1442 
2821-2 
1403-3 
2 - 2311's 
1 - 2401-3 
1 - 2403-3 
1 - 2803 


Also on order are 2 Model 65's to be installed in the 
Bendix phased-array radar FPS-85. These and a 
Model 30 will be installed during fiscal year 1967. 
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C. Current Status 


C. 1 Major proposal effort was a no-bid technical report to the 

Air Force on IBM project FORCE. This was for replacement 
of the data control computer. It will come back out for bid 
in 1966. Only one manufacturer submitted a bid to replace 
the four 7094’s involved - (Eglin, Wright-Patterson, Edwards 
and BSD). That manufacturer was CDC and they failed to 
demonstrate the 26 bench marks successfully. 
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IBM Strategy 

Air Force program and all concerned local reps are staying aware 
of the second attempt to create "specs. " We are also praying for 
delays in this preparation. You might help here. 
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Schedule of Key Target Dates 


Doesn’t affect MOL, but the ’’specs" will most likely appea.r before 
August 1966. 
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G. Competition 


CDC - probably hottest. 

G E - - _ 

* Toss-up for second until we see the new "specs" 

Remington- 
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DOUGLAS AIRG. ' C T COMPAN 


Missiles and Space 
Systems Division 


Sv ta Moni 
Cu v* Ci t'j 
Hun . g t o n 


Calif. 
Calif, 
ich, Calif 



IBM Coverage 

District 20 

Branch Office- L.A. Scientific 

Los Angeles Aerospace Bldg. 

Branch Manager - Cal Thimsen 

Acct. Mkt. Mgr. - Bill Mais 

Senior Marketing REp.- Bernie Rucks 

MSSD Team Leader - Tony Monaco 

MSSD Marketing Reps.- Ron Hillblom, 

Bill Hess 


FSD Representative - Bill Hubbarth - Manager 

Mission Simulator Project 
(located at Douglas Aircraft Co) 

John Jones, Los Angeles. 
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Douglas MOL Organization 


Vice President 

MOL Subdivision - R.L. Johnson 


Assistant to Vice President 

MOL Advance Mission Office - G.V. Sutler 


Director * 

MOL Configuration Management - G.G. Wray 


Manager 

MOL Program Security & Adminiswtration - J . P . Chilton 


Director 

MOL ENgineering and Integratio n - DR. A.F. Johnson 


Manager 

MOL System Engineering - S.M. Robinson 


Manager 

MOL Development Engineering - F.W. Murphy 


Director 

MOL Orbiting operations & Support - J.S. Sogg 


Director 

MOL Procurement and Production - S.P. Dillon 


Director 

MOL Vehicle Flight Rediness and - S.D. Truham 
Product Assurance 


Director 

MOL Program Control - G.J. Askew 
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B. BACKGROUND 

B.l Role in MOL 

Douglas is the prime contractor to the Air Force 
for the MOL Orbiting Vehi le. This includes the 
Vehicle, Crew living quarters, Crew working 
quarters or laboratory. Life supprrt systems. Data 
systems and Data Management, Systems integration, 
and Mission simulation. The On board experiments 
(payload), are being provided by General Electric 
by a prime contract to the Air Force. 

IBM is vitaly interested in two of the ground 
support activities associated with Douglas's role 
in the MOL Program. 

1. Vehicle Check Out 

We have had no significant involvement in this area 
to date. This wi 11 require a significant amount of computing 
equipment, and represents an opertunity to get into 
an area where competative equipment has been heavily 
used. 

2. Mission Simulation 

The primary purpose of the mission simulator will 
be for crewtraining, (both flight and ground crews). 
However it will also be required for on orbit 
support functions such as contingency rescheduling, 
re-entry rehersal , and malfunction analysis, as well 
as postflight ana lysis. 

The simulator will include vehicle replicas, 
instructors control consoles, local and remote 
visual displays, experiment simulators, GFE Gemini 
simulator, and a computer or computers. 

A large scale computer will be required to handle 
various functions: Simulation of the on board 
computer, simulation of the external environment, 
interface to experiments, consoles, displays, and 
Gemini simulator, Simulation monitoring, data 
reduction and evaluation. 

Two Mission simulators will be required. One will 
probably be located at Douglas and the other 
at Vandenberg Air Force Base. The One at Douglas 
will be used for Check out of equipment and 
programs, and for flight crew training. The simulator 
at Vandenberg AFB Will in addition be used for 
ground crew training and for total flight rehersals. 
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B.2 Equipment Installed - Douglas MSSD 


IBM Systems Installed 

4 - 7094-1 

2 - 7010 

3 - 1460 

4 - 1401 

One 7094 is purchased, the rest of the equipment 
is rented. 

Total system points installed - 400,000 


IBM Systems on order 

8 - System/360 Model 20 

5 - System/360 Model 30 

7 - System/360 Model 50 

2 - System/360 Model 65 

It is expected that the number of Model 50 systems 
will be adjusted downward thd the number of model 
65 systems will be increased. 


Competitive Systems Installed 


There are several small and intermediate systems 
(CDC 160A - 924 type) used for data reduction and 
conversion and for systems check out. 

Bendix-CDC G-15's are used in several locations 
for quick access computing. 

A considerable amount of time is being purchased 
on a CDC 3600 for running large FORTRAN jobs, but 
no large scale competitive systems are now installed. 
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C. CURRENT STATUS 


C-l Proposals Outstanding 

IBM Federal Systems Division Currently has proposals 
into Douglas for the Data Management and Mission 
Information Systems. Decision on these is expected 
imminently. 

C-2 Current Activity 

FSD is currently working on a funded study contract 
to develope specifications for the MOL Mission 
Simulator. This study is expected to last until 
early 1966, at which time there will be an RFP for 
the simulator. Other participants in the study in 
addition to the Douglas and Ibm Groups are: Link, 
General Electric, and Mesa Engineering. IBM however 
Has the major share of these sub-contracts. 

Bill Hubbarth, IBM FSD Owego, is in charge of 
this study for IBM, and has about six people 

located at Douglas as well as numerous people in Owego. 
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MOL MISSION SIMULATOR 

STATUS: 

° Under Contract to DACo for Definition Phase. 

° Just extended five weeks to February 25, 1966. 

0 $130-135K. 

° Total of fourteen people in Program. 

PHASE II PROGRAM FOR IBM 

° Douglas ''Make" for total MS. ($43 million total MS Estimate) 
° Competition - March & April. 

° IBM Major Thrust for MS Data Handling System - $14. 2 million. 
Computer Complexes 
2 360-65' s 
4 360-50’s 
2.-4 1800's 
($8 million) 

- Instructor Consoles 
8 2250's 

Special Hardware 
($.7 million) 

Software 

100-150 man years 
($3-4 million) 

- MS System's Engineering & Support 
($1-1. 5 million) 
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COMPETITIVE STATUS 

° IBM Equipment being used as baseline. 

° IBM receiving 2 to 1 more money than Link, PRC. 

° PRC wants software-historical relation to DACo. 

° CDC Background in DACo, PRC. 

° Tied to DMS. 

° DACo concerned about 360 delivery. 

° IBM has been major source of MS requirements definition. 

CURRENT APPROACH 

0 Strong role in MS Specification. 

° Major software planning effort underway. 

° Major effort in Instructors Console. 

° Attempt sole source. 
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D. PROBLEM AREAS 


The current problem area is associated with the 
Simulator study. The Study is proceeding according to 
the contract schedule.. However, much of Ithe data 
necessary is not yet available, and many necessary 
decisions are not yet made. This necessitates the 
making of j udgement deci si ons in the simulator 
design which may well be subject to major when the 
facts all all available. Areas where information is 
lacking include: Mission Payload, and Onboard computer 
where the winning design is not known. 


Section 4.1 


Page D/1 
12/20/65 



IBM CONFIDENTIAL 


Conference Notes - Discussion regarding Douglas Checkout 

requirements Document #A3-802-E100-12 
of January 6, 1966. 

Attendees: C. B. Brown* G.C.Boruski, K.Gajewski, 

W.Gourlay,Jr., R.C.Heath, A.J.Monaco, 

F.X.O'Rourke, A.L.Ryff, L.Stoller, J.Sugi, 
C.D.Thimsen. 


1) Page 2 of this memorandum summarizes pertinent conclusions 

arrived at after analysis of the Douglas Technical Guidelines document 
for a computerized checkout complex. 


2) Page 3 tabulates some major technical problems associated 

with implementing the requested approach using IBM equipment. 


3) At the conclusion of the meeting it was agreed that an effort 

would be made to respond at least to the preliminary request by Douglas. 

It was further agreed that initial meetings would be scheduled with Douglas 
personnel as soon as possible, in that a competitive analysis would be 
completed to establish cost guidelines, using the SDS 9300 versus both 
the 360/44 alone and the 360/44 with an 1800 front end. 


FXOR:jh 



cc: W.B.Gibson, J.E.Hamlin, W.Hess, J.P.Jones. 
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SUMMARY 


1. Requirement seems to be generated around specific computer 
(SDS 930 or 9300). 

2. Well suited for checkout application. Obviously generated using 
SIVB background and personnel. 

3 . Implementation of such a system would require significant FSD 
support. 

4. Delivery cycle most probably would not exceed 12 months even if 
MOL slips further. 

5. To respond would require commitment of at least 4 360/44 systems and 
up to (8) 1800 1 s . 

6. Response would require high level engineering liaison with Douglas 
for next 6-8 weeks . 

7. Present efforts here (DIMAC) dovetail very well with Douglas basic 
requirement. 

8. Must make decision whether to: 

a. Respond 

b. Level of response 

c. Availability of 360's/1800's. 

d. Availability of engineering (FSD) 

e. Funding 

9. If we are going into checkout, we must start here. This will require 
equipment committed for checkout only. 
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Requirements 

I, Independently addressable memory modules 
c n 

0 

S 2. Memory expansion to 65K 
o 

^ 3. Memory operation/external equipment 

I — 1 

4. Auxiliary storage (SDS 3300 type requested) 

5 .. Program I/O channels (24 bit parallel - 
minimum rate 100K words/second). 

6. Telemetry channel with DBAS type 

buffering. 

7. Buffered Display output - highly probable 
same requirement to work with existing 
displays at test site only. 

8. Test Equipment Interface 

9. DO/DI requirements 

10. ”Nested" priority interrupt(10 levels 
requested.) 

II. Instruction Interrupt (unique instruction re¬ 
lated to particular line) 

12. Paper tape punch 

13. Memory incrementing 


360/System 

Cannot be handled per se 

Cannot fulfill as portion of this capability used 
to meet peripheral requirements 

Cannot handle completely - partly satisfied 
by RPQ 

Cannot meet access time with disc. Using drum 
cannot meet transfer rate. 

Requires RPQ 

Requires RPQ fcr input + assignment cx some 
360 memory as buffer. 

Requires 2250 display concept With some 
interface RPQ 

RPQ required 
RPQ required 

360/44 cannot meet requirements as stated. 

RPQ route may be difficult. 

RPQ, possibly dealing with basic logic, 
required. 

Externally purchased equipment 
Not in 360/44 repertoire 


360+ 1600 Front End 


Can hand 1 e actual 
requirements 

Can meet and exceed 
requirements 

Requirements met 
with RPQ 

(Same as 360) 

Requires RPQ 

RFQ fcr Channel 1800 
memory as burner (wiii 
meet highly probable 
expansion requirement s 

(Same as 360) 

RPQ required 

RPQ required 

1800 system can handle 
basic requirements 

1800 can handle most 
of requirements 

(Same as 360) 

Not in 1800 
repertoire 
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February 8, 1966 - 


TRIPREPORT - DOUGLAS, HUNTINGTON BEACH 


Re: 


Douglas Checkout System Meeting, February 7, 1966 


Attendees: T. J. Eason - MESA 

J.H.Lane - Douglas 
A. Monaco - IBM 
J. Sugi - IBM 


J. Jones - IBM 
C, Brown - IBM 
R. Heath - IBM 
F.X. O'Rourke - 



1. GENERAL RESULTS: 

Douglas, over the past eight months, has worked very closely with MESA 
personnel and three computer manufacturers (CDC, SDS, CCC) in 
optimizing digital hardware for implementation of a "Modular Unified 
Checkout Concept". A well-qualified group of programming consultants 
(MESA), together with their own systems group (experienced in SIVB checkout 
problems) have completed definition of the Douglas MOL checkout concepts. 
The actual specifications for this hardware have been written by MESA with 
T. J. Eason responsible for its final generation. IBM was not a participant 
in any phase of this effort. 

During the discussion (approximately 52 minutes) the following specific 
points were presented by Mr. Eason of MESA Corporation: 

a. The resultant checkout concept is directed towards a unified 
system which is partially modular in design. They feel the system 
is capable of integration with future checkout requirements. 

b. The system is intended for installation at three sites (pricing 
for up to six systems has been requested by Douglas). 
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Trip Report, Douglas 


February 8,1966 


c. The system will be required during the vehicle launch 
countdown operation. Therefore, it could eventually become a 
"launch critical" system, similar to APOLLO SLCC at Cape Kennedy. 

d. Prime software goal for this system is to produce a test engineer 
oriented launch language similar to STOL or ATOLL with on-line 
capabilities to modify and assemble test procedures, utilizing 
personnel with little or no training in digital computers or programm¬ 
ing fundamentals. 

e. The system as planned will accommodate all of the Douglas MOL 
checkout requirements (including the data management package). 

f. The hardware interface will have to be such that the system will 
be capable of working with Douglas developed operator consoles and 
color displays. 

g. As presently configured, the system-does not have a program 
regeneration requirement and the specification currently being pro¬ 
cessed for transmittal to vendors does not have any specif ic hard¬ 
ware requirements oriented towards error recovery procedures. 

h. The specification is limited to hardware requirements only. No RFP 
regarding the associated software package will be generated, as 
current plans are for Douglas system personnel to handle this task 
directly with possible sub-contracts to MESA Corporation for 
additional programming help, if needed. 

i. Consideration will eventually be given to utilize this system as 
the Central Computer and monitor element to service remote display 
facilities at the launch site. 

j. The final specification (assumed to be part of the forthcoming RFP) 
has been completed and should be ready for issue from Mr. Hansen's 
(Douglas) office in about two weeks. 

k. Mr. Eason stated that the drum requirements specified in the initial 
technical guidelines document was indeed required for the application 
for which this system is intended, and data transfer rates below 
200,000 words per second would be unsatisfactory. 
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l. Mr. Eason also stated that the expandable memory require¬ 
ment should provide a capability for increasing the memory from 
32K to 65K on site with approximately two to three days of down 
time. 

m. Mr. Eason stated that the final specification would be almost 
identical to technical requirements presented in the guidelines 
document (of which we have a copy). He further noted that there 
would be little or no additional requirements in the specifications 
related to hardware requirements other than normal "boiler plate" 
items normally in a formal RFP. 


2. SUMMARY: 

The Douglas system design has progressed to a point where associated 
Douglas engineering personnel are completely sold on the concept pro¬ 
posed in the technical guidelines document and any attempt to seriously 
influence a modification of the overall concept would have little chance of 
success- 


Within the present IBM structure, it will be impossible to generate either 
a reasonably competitive bid or a suitable technical response to the 
Douglas requirements for the following reasons: 


a. IBM does not have existing equipment capable of meeting the 
basic requirements of the Douglas specification (see conference 
notes, Douglas checkout requirements, F.X.O'Rourke, dated 

31 January, 1966). 

b. A system configuration only approximating the basic requirements 
has been conservatively priced out at about twice the price of other 
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vendors currently under active consideration by Douglas. 

c. Engineering rapport with Douglas checkout personnel is non¬ 
existent at this time. 

d. The engineering effort required to generate a representative 
response to any Douglas RFP would require a considerable 
expenditure of IBM marketing/Engineering funds which, as of this 
writing, are not available for this task. 


3. RECOMMENDATION : 

The Douglas portion of the MOL checkout market has been formulated to a 
point where any further effort by IBM to break into this market would be of 
little consequence. The writer therefore recommends that no detailed 
engineering effort be continued by IBM for purposes of capturing the Douglas 
portion of the MOL checkout market. 


FXOR:jh 

cc: J. E. Hamlin, 
W. B. Gibson, 
Attendees, 

W. Gourlay. 
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February 8, 1966 


TRIPREPORT - DOUGLAS, HUNTINGTON BEACH 


Re: 


Douglas Checkout System Meeting, February 7, 1966 


Attendees: T. J. Eason - MESA 

J.H.Lane - Douglas 
A, Monaco - IBM 
J. Sugi - IBM 


J. Jones - IBM 
C. Brown - IBM 
R. Heath - IBM 
F-.X.O'Rourke - IBM 


1. GENERAL RESULTS: 

Douglas, over the past eight months, has worked very closely with MESA 
personnel and three computer manufacturers (CDC, SDS, CCC) in 
optimizing digital hardware for implementation of a " Modular Unified 
Checkout Concept". A well-qualified group of programming consultants 
(MESA), together with their own systems group (experienced in SIVB checkou 
problems) have completed definition of the Douglas MOL checkout concepts 
The actual specifications for this hardware have been written by MESA with 
T. J. Eason responsible for its final generation. IBM was not a participant 
in any phase of this effort. 

During the discussion (approximately 52 minutes) the following specific 
points were presented by Mr. Eason of MESA Corporation: 

a. The resultant checkout concept is directed towards a unified 
system which is partially modular in design. They feel the system 
is capable of integration with future checkout requirements. 

b. The system is intended for installation at three sites (pricing 
for up to sjx systems has been requested by Douglas). 
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c. The system will be required during the vehicle launch 
countdown operation. Therefore, it could eventually become a 
"launch critical" system, similar to APOLLO SLCC at Cape Kennedy. 

d. Prime software goal for this system is to produce a test engineer 
oriented launch language similar to STOL or ATOLL with on-line 
capabilities to modify and assemble test procedures, utilizing 
personnel with little or no training in digital computers or programm¬ 
ing fundamentals. 

e. The system as planned will accommodate all of the Douglas MOL 
checkout requirements (including the data management package). 

f. The hardware interface will have to be such that the system will 
be capable of working with Douglas developed operator consoles and 
color displays. 

g. As presently configured, the system does not have a program 
regeneration requirement and the specification currently being pro¬ 
cessed for transmittal to vendors does not have anyspecif ic hard¬ 
ware requirements oriented towards error recovery procedures. 

h. The specification is limited to hardware requirements only. No RFP 
regarding the associated software package will be generated, as 
current plans are for Douglas system personnel to handle this task 
directly with possible sub-contracts to MESA Corporation for 
additional programming help, if needed. 

i. Consideration will eventually be given to utilize this system as 
the Central Computer and monitor element to service remote display 
facilities at the launch site. 

j. The final specification (assumed to be part of the forthcoming RFP) 
has been completed and should be ready for issue from Mr. Hansen's 
(Douglas) office in about two weeks. 

k. Mr. Eason stated that the drum requirements specified in the initial 
technical guidelines document was indeed required for the application 
for which this system is intended, and data transfer rates below 
200,000 words per second would be unsatisfactory. 


Section 4.1 


Page H/9 
2/18/66 





IBM CONFIDE NTIAL 


Trip Report, Douglas 


February 6, 1966 


l. Mr. Eason also stated that the expandable memory require¬ 
ment should provide a capability for increasing the memory from 
32K to 65K on site with approximately two to three days of down 
time. 

m. Mr. Eason stated that the final specification would be almost 
identical to technical requirements presented in the guidelines 
document (of which we have a copy). He further noted that there 
would be little or no additional requirements in the specifications 
related to hardware requirements other than normal "boiler plate" 
items normally in a formal RFP. 


2. SUMMARY: 

The Douglas system design has progressed to a point where associated 
Douglas engineering personnel are completely sold on the concept pro¬ 
posed in the technical guidelines document and any attempt to seriously 
influence a modification of the overall concept would have little chance of 
success,. 


Within the present IBM structure, it will be impossible to generate either 
a reasonably competitive bid or a suitable technical response to the 
Douglas requirements for the following reasons: 


a. IBM does not have existing equipment capable of meeting the 
basic requirements of the Douglas specification (see conference 
notes, Douglas checkout requirements, F.X,O'Rourke, dated 

31 January, 1966). 

b. A system configuration only approximating the basic requirement: 
has been conservatively priced out at about twice the price of other 
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vendors currently under active consideration by Douglas. 

c. Engineering rapport with Douglas checkout personnel is non¬ 
existent at this time. 

d. The engineering effort required to generate a representative 
response to any Douglas RFP would require a considerable 
expenditure of IBM marketing/Engineering funds which, as of this 
writing, are not available for this task. 


3. RECOMMENDATION : 

The Douglas portion of the MOL checkout market has been formulated to a 
point where any further effort by IBM to break into this market would be of 
little consequence. The writer therefore recommends that no detailed 
engineering effort be continued by IBM for purposes of capturing the Douglas 
portion of the MOL checkout market. 
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cc: 


J. E. Hamlin, / 
W. B. Gibson ,\/ 
Attendees, 

W. Gourlay. 
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MOL STANDARDIZED CALL/TRI? REPORT (IBM CONFIDENTIAL) 


Customer/Prospect Name (1) Douglas Aircraft Corporation _(15) 

Individual(s) contacted (16)_(59) 

Your Name (60) F. X. O'Rourke _(70) Date (71) April 1, 1966 _(76) 

Summary of Facts Covered: 

During this meeting, preliminary engineering requirements for the Douglas MOL 
Data Reduction Task were presented to IBM by Douglas personnel. The discussion 
lasted approximately 2.5 hours, during which the following points were 
highlighted: 

1. The Douglas Data Reduction Group is in the initial management approval 
phase of defining requirements for developing and installation of a large, 
comprehensive data reduction facility, utilizing a high speed general purpose 
computer to automate the Douglas MOL Data Reduction Task. This group 
presently feels the step is mandatory, due to the large amount of data to be 
handled. They further feel that requirements for quick look data, as well as 
10-24 hour turnaround analysis functions, can only be handled by a highly 
automated central facility, which, at present, does not exist at Douglas. 

2. They presented the following preliminary load figures for this center (which 
after review with the contractor and other Douglas departments were felt to be 
conservative). 

Item a - The total data rate estimate; 

Vibration and Acoustic Data 21.9 x 10 words per 24-hour day, 

FM data 5.33 x 10^ words per 24-hour day, 

PCM data 60 minutes of airborne tape data plus 90 minutes of real 
time data daily. 

Item b - Real time data input loading requirements; 

1. decommutating and formatting airborne recording - 3-1/2 hours 
general decommutating and formatting - 1/2 hour 

scale conversion tasks - 1-1/2 hours. 

2. End to end merge, redundant edit of overlapped airborne 
real time - 3 hours. 

shock and vibration analysis -1.4 hours 
PCM event data -1.5 hours 
Biomedical data - 1 hour 
Function merge - .25 hour 
comparison to nominals - 1 hour 
Propulsion system analysis - 1 hour 
engine analysis - 1-1/2 hours. 
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The above is not a complete list. The total processing requirement per day, 
however, did come out to 29.1 hours. If one computer system is to be used, 
there is a basic requirements that processing must go on while data is being input 
to the system and results output to the appropriate displays and recording devices. 
In most instances, compilation and assembly must be performed concurrently by 
the system. 

3. They are presently planning to do a good deal of their own programming but 
clearly recognize the requirement for the computer vendor to provide system 
programming support at least during the initial phases of the system development, 
especially in the Monitor and operating areas of the software. 

4. It was indicated the system should be fully operational by July, 1967. In 
this regard, they recognized the firm requirement to utilize machine time available 
at other locations, starting early in September, 1966, for checkout. They were 
especially interested in developing and expanding multiprocessing and multi¬ 
programming aspects as a solution to this problem. 

5. The IBM hardware configuration under consideration by them included a 
360/44 with 65K of memory as the central processing element with one completely 
implemented and buffered 2250 display and one 2260 maintenance console, six 

to eight tape drives (4 to 6 of which would be 180 kc) and at least two high speed 
multiplex channels for tape and disk operations. Memory requirements of this 
system definitely include a large disk file to handle the many long term storage 
requirements (including calibration curves, reduction matrix data, engineering 
conversion data, etc.) . 

The first meeting was concluded with an agreement on the part of IBM to return 
the week of 28 March to become more familiar with the detailed task loading for 
the system, IBM would then present a proposed hardware configuration, together 
with a detailed outline of the required software package required to handle this 
task. It is apparent that during this presentation IBM must be ready to discuss 
details of the software support IBM feels would be necessary to handle the 
problem and to describe the general manner by which the software will handle 
the "multi-programming" requirements. 

GE NERAL COMMENTS 

The task, as described, is comprehensive one for a single computer system. Some 
serious questions exist regarding the use of the 360/44 system for this task, as 
the monitor package associated with the 360/44 does not, at this time, have any 
ability to handle input and output concurrently with the telemetry processing 
requirements. 

R. Cabaniss is presently looking into the feasibility of modifying the 360/44 
monitor software package to perform this task and is planning to develop a reason¬ 
able estimate of what an effort of this nature would require in the way of manpower 
and time. 
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CUSTOMER NAME: General Electric Company 

Space Technology Center 
Goddard Boulevard 
King of Prussia/ Pennsylvania 13406 
Telephone: 969-2005 

& 

General Electric Company 
Re-Entry Systems 
3198 Chestnut Street 
Philadelphia/ Pennsylvania 19101 
Telephone: 823-2005 


REGION: Eastern 


DISTRICT: 5 


BRANCH: 


P hiladelphia 


BRANCH MANAGER: R. J. Dougherty 


DP SALESMAN: 


F. A. Fisher 
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A- 1 - Missile and Space Division - Plant Locations 


Valley Forge Space Technology Center 


Cabot, Cabot & Forbes Complex 


Philadelphia 


Burlington 


Daytona 


Houston 


P.O. Box 8555 
Philadelphia, Penna. 19101 

Spacecraft Dept., P.O. Box 8661 
Philadelphia, Penna. 

Re-Entry Systems Dept. 

3198 Chestnut St. , Phila. , Pa. 

Missile and Armament Dept. 
Lakeside Ave. , Burlington, Vt. 

Apollo Support Department 

P.O. Box 2500, Daytona Beach, Fla. 

Apollo Support Department 
P.O. Box 26287 j Houston , Texas 


Huntsville Apollo Support Department 

P.O. Box 294, Huntsville, Ala. 

Maryland Spacecraft Department 

4901 Fairmont Ave. , Bethesda, Md. 


Mississippi Mississippi Test Support Dept. 

Bay Saint Lanes 
Mississippi 

Evendale Space Power Propulsion Dept. 

Mail Drop R-2 
Cincinnati, Ohio 
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E.A. Miller 

General Manager of MOL 

C.F. Hix, Jr. 

Manager Design Engineering Section 

R. W. Lawton 

Manager Bio Astronautics Section 

K. Kitson 

Manager Program Management Sec. 

R.G. Myers 

Manager Major Sub-Contract Sec. 

A.E. Buescher, Jr. 

Manager Business Management 

L. P. Huggins 

Manager Manufacturing Section 

G.E. Eastwood 

Manager Systems Test & 

Deployment Section 

E.T. Brogan 

Manager Quality Assurance & 
Reliability 

R.J. Haughton 

Manager Employee & Community 
Relations 

J. C. Hackney 

Manager Finance 


A-l - PERSONNEL PROFILE 

H.W. Paige 

Division General Manager 

E. L. Hulse 

Division Financial Manager 

L. Cimino 

Division Manager of Information Systems 
Computer Center 

R. Hench 

Manager of Programming 

F. Garrison 

Manager of 7094 Operations 

M. Morton 

General Manager - Re-Entry Systems 

L. Cowles 

General Manager - Spacecraft Department 

L. Steg 

Manager - Space Sciences Lab 
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B - BACKGROUND 


B-l Customer is a prime contractor along with Douglas Aircraft. 

Other programs include NIMBUS, APOLLO, SUPPORT, RE¬ 
ENTRY SYSTEMS, VOYAGER 

B-2 One (1) 7094 System (main frame) approximately $60, 000 month 
rental purchased by G.E. and sold by G.E. to third party (CEIR) 
- Presently leasing from CEIR. Approximately 16 Tape drives 
(729*s) not purchased. 

One (1) 7094 System (main frame) approximately $60, 000 month 
rental. 10 Tape drives (729-6 J s) not purchased. 

One (1) 1460 System (dual printers) 

One (1) 1620 System 40K 

G.E. Systems - 

2-415 ! s 
1-225 

1- 235 

2- 625 ! s (on order) 
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C Proposal for purchase of second 7094 System. Purchase of 
main frame approximates $1,350,000. 
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E. G.E. dedicated to ultimate replacement of IBM computers 
with their own. As such, we are pushing purchase of 
second 7094 system. 

Replacement of 1620 with 1130. 
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CUSTOMER NAME: 


The Denver Division of 

The Martin Company 

The Aerospace Division of 

The Martin-Marietta Corporation 


P . O. Box 179 

Denver 1, Colorado - (303) 794-5211 


REGION: 


District 15, Western Region 


BRANCH MANAGER: 


N. H. Hawkins 


MARKETING MANAGER: 


Robert Umbreit 


MARKETING REPRESENTATIVE: 

ADVISORY SYSTEMS 
ENGINEER: 

MOL PROJECT OFFICE: 


Richard Winckler 


Jack Stunkel 


F. X. O'Rourke 
W. Gourlay 
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1. DIMAC Study 

The Martin organization supports both a functional organization and a 
project organization. These two operate in parallel. A given effort or 
individual may, at various stages of a project, report through both of 
these channels. Martin also establishes special teams or task forces to 
respond to RFP's and any other requirements for special study efforts. 

The DIMAC effort is, at present, a special team effort being "vectored'' 
and define < by K, Gunderson. 

2. General Organization 

Martin Denver Divisional Vice-President - J. D. Rauth, 

Executive Directors - Functional - I, N. Palley - Technical Operations 
Responsible for Research, Engineering, Manufacturing, Testing, Training, 
Quality, Material and Procurement. 

- D. S. Burrows - Management Oper’s. 
Responsible for Administration (D, P. Equipment), Finance, Account ing. 
Plans and Budgets. 

General Managers - Project - R. S. Williams - Strategic Systems (Titan II) 

- W. G. Purdy - Launch Vehicles (Titan III) 

- G. E, Smith - Military Space Stations 

(Apollo pallet). 


Management Concerned with DIMAC* Effort - 
W. G. Purdy - General Manager, Launch Vehicles. 

D. S. Levine - Program Director, Titan III. 

L. J. Adams - Technical Director, Launch Vehicles 
S. F 0 Albrecht - Manager, Ground Electronics 
W t J. Hughes - Project Engineer ILC ** 

D. Gray - Project Manager ILC 

K. Gunderson - Senior Engineer ILC - DIMAC 

B. Pennington - Senior Engineer ILC - DIMAC 
J. Hoerning - Senior Programmer ILC - DIMAC 

Management Concerned with Conventional DP use - 

D, S. Burrows - Executive Director, Management Operations. 

R. E. Weber - Director, Administration 

C.Izett - Staff - Conversion Program 

J. Hopko - Manager, Management Operations (Mgt. Engin.) 

J, E.Feely - Manager, Computer Department 

E. J. Karulf - Manager, Technical Operations (Mgt. Engin. ) 

* - DIMAC - Data integration and malfunction analysis computer is the 
computational system proposed by Martin for use in the . 

ILC - Initial Launch Capability (ILC) ground station for T-IIIC - 
MOL Launch. 
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Air Force Management Concerned with DIMAC - 
Colonel Miller (ETR Study) 

Captain N. R. North - Space Systems Division (SSD S.S BTA)643-1402, L. A) 


Aerospace Corporation personnel Concerned with DIMAC 
Jay J. Kimose (Los Angeles) Titan III G-50 - 648-5536 
S. H. Lewis, Electronics Division 
N. L. Gelbwaks, Electronics Division 
W. Dillon ETRO - 305-853-5695 


As the DIMAC effort progresses, a more detailed organizational 
structure will be included where it is directly related to the DIMAC 
effort. 
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DIMAC EFFORT 


B. BACKGROUND 

The current role of the Martin Company in the MOL Project is to provide 
the Titan III-C booster for launch of the MOL payload. In this regard, 
Martin has contracted with the Air Force to provide a proven element of 
the system on the basis that the Titan booster has been operationally proven 
over the last three years. Within this task Martin is also responsible for 
the checkout and certification of the booster vehicle and have stressed to 
the Air Force that booster reliability is not only based upon the proven 
components of the vehicle itself but the proven concepts of checkout and 
launch control techniques currently being utilized by Martin at the Cape 
(KSC). They, however, do recognize the need for more pertinent and timely 
technical information associated with vehicle checkout and launch to enhance 
their "launch on time" capability and speed-up existing booster checkout 
procedures. The Martin Company has been strongly entrenched in the 
aerospace booster business for the past nine years and is the prime con - 
tractor for the Titan booster vehicles currently being used on the Gemini 
program and as the major ICBM Air Force weapon. At present, Martin 
is actively engaged in production of the Titan II vehicle for the Air Force 
and the Gemini program. In this regard. Titan II is considered a major 
ICBM missile and the Titan III a vehicle being developed for USAF MOL 
applications and many NASA tasks (including Surveyor). 

Martin-Denver has also recently been awarded a four month study contract 
on the order of $400,000 for the development of the Apollo extension system 
experiment al pallet. In this regard, three other vendors have also received 
the study award. One of the four will be awarded the contract to develop 
the payload equipment for the Apollo extension effort. Martin has aligned 
themselves with RCA for development of the electronics and computation 
equipment and Honeywell for the platform and guidance systems. 

It has been established that Martin-Denver will have significant respon¬ 
sibility at Vandenberg Air Force Base in the development of the launch 
and checkout procedures associated with the Titan booster vehicles they 
are delivering there for MOL. 

Equipment Installed at Martin-Denver 


There is currently over 200, 000 points of IBM equipment installed at 
Martin-Denver. The equipment includes a 7094-2, a 7074, a 7044, 2 System 
/360 Model 30’s, 3-1620's and 10, 000 points of unit record equipment. 
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The following Table 11 

sts equipment installed together with monthly 

rental costs and appli 

cation. 



- 


MONTHLY 


ITEM 

NO. 

RENTAL 

APPLICATION 

7094 Model 2 

1 

85, 445 

Dc Processing/Engineering App 

7-074 

1 

38,925 

Ac anting 

7044 

X 

34,595 

Ge al 

1401 

1 

9484 

7044 peripheral 

1401 

1 

9696 

General 

1620 

3 

5420 ) 




3925 ) 

Scienct'" c 



5390 ) 


360/Model 


7975 

Data Reduction 

30 


6775 

Peripheral Support 


t 


In May of 1965, the Martin Company (all three divisions) made a decision 
to replace all of the installed IBM systems with GE 635 multiprocessing 
systems. The planned conversion is to start on December 15, 1965, with 
temporary installation of a GE 625. The dual 635 system is to be 
installed in June of 1963. The last major IBM system at Martin is sched¬ 
uled to be displaced in late September, 1966. The actual decision to utilize 
GE equipment instead of IBM was made by the president of the Martin- 
Marietta Corporation (George Bunker), overruling unanimous recommend¬ 
ations for IBM from each of the three divisions and the Martin Company 
headquarters. It is believed that this decision was the result of a close 
working relationship between Mr. Bunker and Mr. Raeder, President of 
GE Computer Division. The relationship was established during exchanges 
relative to the Bunker-Ramo Company, a portion of the Martin-Marietta 
Corporation. 'Bunker^Ramo and GE have entered into a series of agreements 

including exclusive exchange of computer patents in several joint proposals 
along this line. 

The possibility of Mr. Bunker personally entering into the vendor decision 
for the DIMAC has been evaluated. It was concluded that while it is not 
impossible, this is a very highly unlikely probability. The DIMAC procure¬ 
ment itself is being handled by the engineering department of Martin. It is 
a procurement for hardware which is a component of a project directed 
and contracted for by the Air Force where the Air Force will be very close 
to the procurement process itself during all its phases. Under these 
circumstances, it will be very difficult for any direct pressure at the 
local corporate level to influence the final decision without this fact 
becoming very obvious to the Air Force itself. 

In summary, while local corporate arrangements have heavily influenced 
IBM’s loss of commercial business in the Martin area, it is not probable 
that any of this influence can be effectively exerted in selection of the 
DIMAC contract. 
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SECTION C CURRENT STATUS 

1. General 


The Martin Company-Denver has prepared a study document describing the 
system requirements for DIMAC. The document outlines the Martin checkout 
philosophy for the Titan booster and recommends an initial configuration for 
installation first at Denver and then at Vandenberg Air Force Base, California. 
The document has been reviewed and tentatively approved by the Aerospace 
Corporation and certain segments of the Air Force. Martin is currently 
awaiting final Air Force approval to go ahead with the project and finalize 
the system specification to issue an RFP. It is expected that the final 
Air Force approval will be forthcoming in late May 1966 at the earliest, 
in that Martin-Denver will have the RFP ready for distribution not earlier 
than July *66. 

It is the stated opinion of Martin-Denver personnel that the Air Force is 
favorably impressed with their proposed passive check-out approach and 
they have, accordingly, estimated the following general schedule regarding 
the development of the system: 

a. Go ahead by the Air Force - end of May, 1966. 

b. Release of RFP by Martin-Denver - end of July , 1966. 

c. RFP response from vendor in Martin-Denver - mid-August, 1966. 

d. Evaluation of proposals - early September, 1966. 

e. Selection of successful bidder by Martin procurement - early Sept., 1966. 

f. Delivery of initial equipment - mid-July, 1967. 

The existing study presently underway with Martin-Denver and IBM is being 
conducted at Cape Kennedy for the purpose of investigating the feasibility 
of using general purpose computers for checkout and launch of Titan III 
vehicle. This study has been assigned the title "OCALA" by IBM at 
Cape Kennedy. The effort is, in general, being coordinated from the 
engineering management aspect by Denver personnel, who are also implement¬ 
ing the applications programming portion of the effort, while the development 
of the monitor and executive programs for the system are being handled by 
IBM at Cape Kennedy. As presently proposed, the group working at Denver 
will transfer to Cape Kennedy early in 1966 for checkout and integration 
of the application programs with the equipment and monitor program. 

Current plans are to support two 
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Titan launches using an IBM 7044 and a 7288 Data Channel installed by 
IBM to check the utility of the system and the associated programs in the 
areas of limit checking of PCM data, as well as basic success criteria 
techniques. The first launch is expected to occur about mid-May, 1966 
and the second, July, 1966. The computer itself may also be scheduled to 
perform some limited malfunction analysis if the study progresses as planned 
The results of the study will, of course, be highly pertinent to the DIMAC 
system concept. Hardware associated with limit checking is currently being 
developed by Martin-Denver personnel using initial specifications generated 
by IBM. This equipment takes the form of comparator channels designed to 
allow high speed comparison of PCM data. Martin intends to supply two of 
these comparison channels for the OCALA system at Cape Kennedy. In this 
regard, a similar type of comparator is required for the current DIMAC con¬ 
figuration, and, in the event IBM produces this system, a requirement for 
the development of this type of a comparator as well as a more sophisticated 
comparator unit for discrete limit checking will have to be developed and 
provided. 

Martin-Denver personnel have defined the system requirements for the 
DIMAC system in quite a bit of detail over the last six months. They have 
studied missile checkout specifications and existing facilities as related to 
their own checkout philosophy and existing Titan III-C launch equipment 
and have essentially finalized the concept they feel optimizes all the related 
parameters within the Martin structure. In essence, the Martin-Denver 
group has already established their needs and goals for this system and are 
well along in the final approval cycle. They have assumed a strong engineer 
ing approach and are actively pursuing this as their goal. If Air Force 
approval is received, they will respond rapidly and firmly along this general 
equipment vector. Due to the strength and direction provided by Martin 
engineering, there is very little chance that any significant modification to 
their system or their proposed schedule can be affected, except directly 
through Air Force channels currently managing the MOL project. A synopsis 
of the current study report being reviewed at this time by the Air Force for 
final computer approval detailing the basic DIMAC system requirements is 
discussed in paragraph 2. 

The Air Force and Aerospace presently are not wholly in favor of the DIMAC 
concept "per se." They do recognize and are sympathetic to the need to 
streamline the checkout and launch of the Titan III C. However, they would 
prefer that all checkout requirements fit into an integrated checkout approach 
that as yet has not been defined. The IBM Advanced Systems Group at Los 
Angeles intends to work very closely with the Air Force and Aerospace in 
defining and implementing this concept over the next three months. In this 
regard, the specification prepared for the Martin requirements (not as yet 
reviewed with Aerospace) has been carefully tailored to integrate with a 
"unified checkout" concept. 
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Following a detailed analysis of the Martin requirements, the Advanced 
Programs Department, Space Systems Center, FSD (Los Angeles), prepared 
a checkout requirements model, Preliminary Sp ecification for the Design 
of <a Monitor and Diagnostic Computer Complex for the Titan III C Vehicle, 
dated February 1, 1966. 
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2. DIMAC System 

In general, the report defines the basic system to a point where IBM 
would initially be capable of proceeding towards defining an effective 
hardware configuration. As the program develops, however, further 
engineering liaison will be required with Martin engineering personnel to 
obtain the additional detailed data pertinent to specifying the final con¬ 
figuration and possible alternates, or interim systems. Specific data is 
still needed in the areas of data formats, recording requirements, off¬ 
line processing requirements, timing, as well as details of estimated 
system capacity to support pre-launch checkout and the countdown at 
Vandenberg AFB. Until this data is available, together with estimates of 
table sizes, data transfer requirement between devices and processes, as 
well as detailed test requirement specifications, final hardware require¬ 
ments can only be broadly estimated. 

A study of the ILC tradeoff study report Martin-Denver document No. 
X3-010, submitted by Martin-Denver on 25 October, 1965, assumes that 
the entire test and operating system program effort will be handled by 
Martin programmers exclusively. From data available at this time, it is 
felt the assumption is generally optimistic, since Martin seems to have 
under-estimated the actual size of a programming effort associated with 
generating checkout and launch control programs. In all probability, the 
contractor supplying the hardware itself will have to assume and plan to 
man some portion of the programming effort, as well as a good deal of 
the overall system engineering coordination and liaison task, since 
Martin-Denver is relatively inexperienced in both the programming and 
the computer aspects of the system engineering involved. The spec¬ 
ification, as written, however, indicates that any RFP generated by Martin 
at this time will be initially for the hardware only . This must, of course, 
include the associated software package and backup' required to allow 
Martin programming personnel to implement the test and operating system 
programs. It is felt the completeness of this software package for use by 
test and system programmers will have a great influence on the final 
selection of the hardware vendor. It is felt some orientation will have to 
be given to key personnel at Martin to orient them as to the impact of the 
programming effort involved in developing a checkout system. Along this 
line, a visit of Martin engineering to the Saturn project being conducted 
by IBM at Huntsville, Ala, and Cape Kennedy, Fla. properly handled 
would give Martin personnel an excellent picture of the actual size of 
such an effort. 

The ILC report discusses the philosophy of system checkout and Martin 
experience with previous systems to point out and justify the need for 
this passive concept. The report is divided into four basic areas: a, data 
handling, b, equipment, c, system operation, d, programming description. 
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a* Data Handling 

The data handling requires the acceptance of up to three PCM data 
streams each at a rate of 345, 600 bits per second and up to four discrete 
serial data streams, each operating at a rate of 245, 000 bits per second. 
The data will be examined by the DIMAC system on a limit/time corelated 
basis to determine the performance status of the vehicle under supervision 
by the system. In the event of deviation from predicted performance, basic 
diagnostic operations will be brought into action to isolate the cause of the 
anomaly, or at least indicate possible sources of the problem. Data to the 
operator will be displayed on a go/no go, criteria basis to the test operators 
The system will also provide the operator with reference material in the 
forms of print-outs and micro-file records of drawings and schematics. 
Additional output will be provided by the system on an off-line basis for use 
as launch vehicle qualification records and trouble analysis documentation. 

b. Equipment 

The general hardware configuration presented by Martin for this applica¬ 
tion consists essentially of: 

A. Three peripheral processors - 1 each to the two PCM streams 
the third for discrete data from the data recording set (DRS) U 

B. One main processor controlling the overall system-accepting 
inputs from the three peripheral processors and pertinent I/O 
equipment. 

C. I/O equipment - line printers, card read-punch, operator 
consoles and displays, mass storage facilities, plotters , and 

D. Special devices. These include in-channel digital comparators, 
special micro-film file and addressing equipment and special 
purpose operator consoles and displays (possibly up to six) - (not 
completely define din this specification). 

c. System Operation 


In general, the PCM data stream will be passed from the ground equipment 
into digital comparators as parallel segments. The data will be compared 
with data from computer stored tables. All PCM data will be screened 
in this manner to ensure as complete a coverage of all vehicle systems as 
is possible. This should enable the system to recognize momentary or 
transient malfunctions for display to the test operator (when required) and 
for trend and malfunction analysis purposes. A more complex in-channel 
comparator must be provided for the Data Recording Set (DRS) data 
stream to test the discretes from the vehicle. This data will be evaluated 
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on a time and vehicle status basis against pre-defined success criteria 
stored in the operating system and test programs. DRS changes will be 
recorded as a printed record and will be passed to the central processor 
for diagnostic work when required. Selected PCM telemetry data will be 
transmitted to the Central Processor for trend analysis, for both short and 
long term histories and predictions. PCM telemetry data will also be 
transmitted to the Central Processor for diagnostic operations in the event of 
any deviation from system norms. The diagnostic or malfunction analysis 
routines in the Central Processor will operate to isolate the cause of the 
problem to assist and alert test personnel in instituting the desired repairs. 
The proposed system will be essentially passive in operation, monitoring 
information channels to assist in system checkout and increase assurance 
of successful launch performance. As proposed, there will certainly be 
some operator input to the DIMAC system, but in the initial phases of the 
effort this input will probably be limited to requests for information by the 
test operator, modification of limit data, and special system status 
conditions associated with the actual countdown. 

The proposal minimizes not only operator input but also data being displayed 
to the extent that data displayed to the two-six display consoles is limited 
to malfunction data and associated information only. It completely excludes 
status and general information data that might be available within the 
DIMAC system. 


d. Programming Description 

The report briefly describes the general programming structure for 
providing an Operating System Executive type program with the test, 
malfunction, and trend analysis programs integrated with this Operating 
System program. The concept, in general, follows very closely the 
present structure of the Saturn launch control computer programming 
effort, with the exception that the operating system in this instance will 
not have active control routines. However, careful design of the passive 
operating system would allow expansion to an active role, with only a 
minimum of program modification in the operating system areas. 
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Presently, the basic requirements of the system defined by Martin 
include: • 


1. the ability to perform malfunction analysis to the black 

box level to allow extremely rapid recovery from a hold during 
checkout or launch activities. 

2. the ability to provide real-time go/no go success criteria 
comparisons as derived from the data recording set (DRS) and 
telemetry instrumentation data of the launch vehicle, including 
guidance functions for checkout, combined system tests and 
launch activities. 

3. The ability to analyze trends for possible detection of 
malfunctions before actual occurrence and for specific mal¬ 
function analysis during checkout and launch activities. 

4. The ability to provide highly applicable displays ( in engin¬ 
eering units), and on-line tabulation of discrete event changes. 

5. The ability to appreciably reduce instrumentation systems 
checkout time while concurrently improving the accuracy of 
associated calibration techniques. 

In summary, the study report was concerned with implementing a means 
of automatic reduction and analysis of data, emanating from the launch 
vehicle and ground equipment. It attempted to define hardware config¬ 
urations from each of several capability levels and recommended an 
"optimized” configuration to satisfy VAFB requirements. The study out¬ 
lined a) the requirements for and capability of the system at several, 
descriptive task levels, b) a block diagram description of the system 
with general requirements and functions of each block with gross data flow 
within the system indicated, c) an initial analysis of the impact of the data 
integration malfunction analysis computer (DXMAC) upon the various 
phases of the ILC program for design through launch, d) the summary 
and recommendations. 

The report is currently in possession of the IBM MOL Project Group 
and is available for review and analysis, as required. 
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There is presently little doubt that internal constraints within Martin 
will prevent delivery of the final DIMAC system much earlier than 
July, 1967. 

It is apparent that Martin-Denver engineering personnel are anxious to 
have IBM assist them in this effort and are most favorably impressed 
at this time with IBM's ability to satisfy their engineering requirements. 
This cooperation has been further enhanced by the ETR effort, which 
has given IBM a legitimate reason for being in close engineering contact 
with Martin-Denver personnel. In this regard, a series of meetings 
and working sessions with IBM and Martin engineering have been 
accomplished on almost a daily basis for the last three months. The 
working relationship has placed IBM in a very preferential position 
within the Martin structure since the work currently in progress in 
Denver associated with the ETR study is closely related to the eventual 
DIMAC concept and the daily information exchange has given IBM a 
much better view of the engineering details of DIMAC than other 
competitors currently interested in the system. This data has and will 
allow a good deal of advance planning and specific engineering design 
geared to the preparation of a proposal to meet any eventual RFP. 

If this time advantage can be utilized in the near future, it will allow 
a thorough definition and configuration of a system to satisfy the 
DIMAC requirements, not only from the standpoint of the present system 
hardware concept, but also from the standpoint of any alternate configura¬ 
tions in the event the price and delivery would preclude a proposal 
based on the prime configuration alone. 
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3. IBM OCALA Study Effort at KSC 

The Eastern Test Range effort currently being supported by Aerospace, 
Martin and the Air Force, and implemented from the equipment and 
programming standpoint by IBM at Cape Kennedy, is being carried on to 
gain experience in the use of an on-line digital computer for data 
analysis during system tests and the actual launch countdown of a 
particular launch vehicle; in this case, the Titan. 

These tests are planned to establish guide lines for developing a firmer 
system concept, hardware design, computer programming requirements, 
manpower and cost requirements, as well as feasibility data for an 
operational system of this nature to be located at the Eastern Test Range 
at a later date, as well as a test bed for determining the feasibility and 
any pertinent problems that would be applicable to the Martin proposed 
DIMAC system. The project titled "On-Line Computer Analysis and 
Launch Assistance (OCALA)" is being managed by SSD/Aerospace with 
Martin-Denver serving as integrators for all efforts pertaining to the 
study definition implementation, installation, and the final study report 
to be provided at completion of the program. IBM, KSC, is presently 
providing the computer system, programming assistance and guidance, 
computer maintenance, as well as pertinent system analysis and feasibility 
engineering. Martin-Denver is providing the special hardware (in-channel 
comparators) together with interface adapters (as well as some 7044 
computer time). Martin-Denver retains configuration control at this time 
for all software and hardware. 

A 7044 computer is being provided by IBM for connection to the existing 
Titan III ground support equipment to conduct feasibility tests. IBM is 
presently implementing the monitor executive program, derived from the 
existing SPADATS monitor program developed by IBM at Eglin AFB. This 
monitor program is being developed to sequence task execution according 
to time, events and operator inputs. This program was checked out at the 
University of Miami in late December, 1965. The on-line connections to 
associated Titan GSE will now be made and operational tests conducted. 
Operating experience will be evaluated in terms of original system design 
criteria. At this time it is planned to support two Titan launches with 
this system in operation. 

Under present plans, the ground support instrumentation role of the VIB 
at KSC will provide access to all of the required signals for system 
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test evaluation on Project OCALA. The IBM 7044 data processing system 
will be tied into the GSE with a minimum of interference, with concurrent 
use of existing ground equipment. The proposed configuration for the 
study includes a 1301 disk storage unit, two 729 V magnetic tape units, 
a 600 line per minute 1403 printer and a 1402 card read/punch unit. A 
physical installation plan has been determined, approved, and is in the 
process of implementation. Data from the PCM links will be obtained 
from the Data Storage Registers in the Astro-Data ground station in the 
instrumentation room. Eight bit syllables will be transferred as they are 
assembled in the DSR to a variable character input (VCIS) sub-channel 
adapter in the IBM 7288. The function of this sub-channel will be to 
provide controls in data buffering to assemble four syllables from the 
telemetry link into one 36 bit computer word. The sub-channel will gate 
the entire 950 syllables from a major frame into a block of computer 
storage starting with the first syllable after the main frame sync pulse is 
received. A similar approach for the data recording set 7 bit character is 
also being implemented to feed this output into the 7044. 

As planned, the computer will maintain a current table of data limits in 
core storage for all PCM syllables. These limits will be transferred to a 
hardware comparator in the PCM interface equipment through a variable 
character output sub-channel (VCOS). Each syllable will be compared 
against the high and low limits as it is transmitted to the VCIS. If it is 
outside the set limits, a bit-will be placed in the 9th position of the syllable 
storage location. An out of limits interrupt will also be signalled to the 
VCOS. The output limit data and input data stream will be synchronized by 
means of the main frame sync pulse at this time. 

Current participation as of January 18, 1966, is as follows: 

IBM 

1 Project Manager 

2 Systems Engineers 

1 Programmer 

1 Programmer* 

Martin 

2 Systems Analysts* 

1 Systems Analyst (Martin-Denver) 

1 Systems Analyst (Martin-Canaveral) 

3 Programmers 

1 DIMAC Engineer Supervisor 

Aerospace 

2 Programmers 


* Part time 
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D. PROBLEM AREAS 

Unresolved elements requiring further effort and careful analysis by 
IBM cover the full spectrum of problems normal to providing this type 
of a system to the Aerospace Industry during the inceptive phases of 
the large Aerospace efforts such as MOL. These general problems 
include: 

1. Ability to deliver the required equipment within the proposed 
schedule constraints (the most serious IBM constraint at this time). 

2. Ability to completely, competitively price the required system 
(IBM is very competitive if the complete package is considered 
and effectively presented to Martin). 

3. Requirement of defining in detail actual system requirements and 
the optimum configuration of the DIMAC system for present and 
future applications. Reference the Preliminary Specification for the 
Design of a Monitor and Diagnostic Computer Complex for the 
Titan III C Vehicle dated February 1, 1966. 

4. Requirement for careful additional analysis of impact of the 
Eastern Test Range study effort (being conducted by IBM) on the 
DIMAC system configuration, as well as the overall IBM 
aerospace effort. 

With regard to delivery problems, data available at this time clearly 
indicates a high probability that the system as presently configured 
may require up to three 1800 systems, as well as a 360/44 configuration 
to be delivered by July, 1967. However, this particular problem as well 
as the competitive pricing problem cannot be fully resolved until a more 
adequate definition of the optimum system configuration has been 
provided, and further data on the MOL Project Office reaction to the system 
proposed by Martin has been obtained. 
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E. IBM STRATEGY 

E. 1 Sales Action Program 

Presently, effort is centered at Denver and KSC and involves the establish¬ 
ment of close communication and engineering liaison with Martin personnel 
at Denver and KSC who are responsible for both the DIMAC system design 
and final evaluation of the ETR study. It is planned to expand this effort 
to the point where Martin-Denver is thoroughly familiar with all unique 
features and advantages of IBM equipment suggested for DIMAC and are 
fully aware of IBM experience in related areas of launch checkout and 
control operations. 

A pre-proposal effort has been initiated to perform a thorough system 
analysis from the hardware and software viewpoint of the DIMAC problem. 
The output of this study will be the definition of an optimized IBM system 
configuration. This task was completed on January 25, 1966. The results 
of this pre-proposal effort will be reviewed by various IBM facilities either 
responsible for development and delivery of the proposed hardware and 
software, or who have personnel experienced in this type of a system 
application. The first such conference is scheduled at the San Jose Plant, 
Special Engineering, on February 15, 1966, and is the first coordination 
effort following completion of the February 1 Preliminary Specification. 
Huntsville, Cape Kennedy and Denver will be visited during the week of 
Feb. 28 - Mar. 4, 1966. Additional coordination will be effected with 
the Engineering Lab, Bethesda and Special Engineering (Poughkeepsie). 

The results of these reviews will be incorporated into the final document 
for use as the basis of any proposal generated by IBM in response to an 
RFP for the DIMAC system. 

At present, the West Coast aerospace MOL group is supporting the 
proposal and maintaining close liaison with Martin-Denver, Aerospace 
Corporation, and the Cape Kennedy OCALA study. At this time, initial 
contact has been established with cognizant personnel associated with 
the ETR effort and the DIMAC effort and meetings have been set up for 
general discussions and common exchange of data regarding the overall 
problem. 

Since the East Coast study is directly related to the DIMAC effort and its 
output and results will largely determine the course of the DIMAC system, 
every effort is being made by the IBM MOL Project Group to insure that the 
ETR study is adequately supported and that proposed schedules are realistic. 
Close engineering monitoring of the progress of this effort will be continued 
through June of 1966 to insure maximum utilization of output of this study 
is made by IBM for eventual incorporation into the DIMAC effort. 
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E.2 Technical Help Required 

A qualified technical engineering team is required to implement the planned 
pre-proposal system study and to review and comment on the study results 
This team is now being assembled under the engineering direction of the 
IBM West Coast MOL Group. 

E.3 IBM System Design 

No formal system design has been completed at this time. A preliminary 
system configuration utilizing a 360 Model 44 and three IBM 1800's has 
been tentatively proposed to Martin personnel. Engineering analysis now 
being performed on this proposal, however, indicates there may be some 
deficiencies in implementing this type of a system, both from the stand¬ 
point of capability of performing the task presently defined, as well as 
ability to expand to what is felt will be future requirements if the DIMAC 
system proves satisfactory. The Preliminary Specification analysis was 
completed January 25, 1966. The document itself is dated February 1, 1966. 
There is a high probability that the proposed system configuration resulting 
from the system study will utilize an IBM 360 Model 44 as the central 
processing element. 

The Engineering Lab (Bethesda) is currently evaluating the initial technical 
approaches and expects to conclude this effort by March 15, 1966. 

Comments to be forwarded to Advanced Programs (Los Angeles) will include 
an engineering critique, recommendations, and ballpark price estimates. 
Special Engineering (Poughkeepsie) is currently examining design require¬ 
ments for a special high speed data acquisition channel somewhat similar 
to the 2909 but with in-channel comparators. Their study is expected to 
conclude on March 1, 1966. 
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F. SCHEDULE OF KEY TARGET DATES 

Since the DIMAC and the OCALA efforts are closely interrelated, there 
are in this case two complete sets of target dates; one associated with 
the development of the DIMAC system, and the other related to the 
development and outcome of the OCALA effort at Cape Kennedy. 

DIMAC Target Dates 

1. Martin tradeoff study forwarded to Air Force - October 5, 1965 

2. Completed IBM pre-proposal effort for DIMAC - January 25, 1966. 

3. Contemplated Air Force concept approval - end of May, 1966. 

4. Release of RFP for DIMAC - early July , 1966. 

5 . Date for reply to RFP - mid-August, 1966. 

6. DIMAC contract award - early September, 1966. 

7. Initial equipment installation at Denver - mid-July, 1967. 

8. Equipment installation at VAFB - early November, 1967. 

IBM OCALA Effort at Cape Kennedy 

1. Initial proposal for study by IBM - late August, 1965. 

2. Air Force approval of OCALA study effort - November, 1965. 

3. Computer system installed at Cape Kennedy - February, 1966. 

4. Checkout and debugging of monitor and applications programs - 
March, 1966. 

5. Use of OCALA system in support of Titan launch - May, 1966. 

6. Use of OCALA equipment in support of second Titan launch at 
Cape Kennedy - July, 1966. 

7. IBM portion of study effort completed - July, 1966. 

8. Results of OCALA study effort published - July/August, 1966. 
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G. COMPETITION 

It is fairly certain that active competition in this area will include 
the Digital Equipment Corporation and Control Data Corporation, with a 
high probability that General Electric will also bid on any RFP. While 
there will probably be others who will receive the RFP when generated, 
it is not expected (at this time) that there will be other significant 
competition due to the complex system analysis requirement in the short 
estimated response time associated with the RFP from Martin. 

At present, the other active competitors, on an equivalent engineering 
status with IBM, include the Digital Equipment Corporation and Control 
Data Corporation. They both have been actively involved in the systems 
design of the DIMAC, but to a much lesser extent up to now than IBM 
has. Both have submitted a preliminary configuration for review by 
Martin who in some cases have commented on their proposal to IBM 
personnel. In this regard, one strong point for the DEC configuration is 
a proposed memory sharing approach which DEC feels would minimize 
inter- system data transfer and would eliminate some timing problems. 

A weak point in the opinion of Martin in the overall approach of DEC to 
this problem is felt to be in the area of programming and equipment 
support DEC would plan to provide. Martin engineering seems to feel 
that they would not have enough programming and equipment support 
from the standpoint of equipment integration, software packages, 
programming assistance, and programmer and test engineering training. 
In this regard, Martin has stated that competent system support in these 
as well as the actual vehicle checkout areas is considered critical to 
success of the DIMAC system. 

RCA submitted a comprehensive analysis of the DIMAC concept late in 
December. During the presentation, they expressed a desire to be an 
active part of this system. They have assigned an engineering team to 
actively monitor system progress. Brief looks at RCA document showed 
it to be well prepared and in consonance with Martin philosophy. 
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BEST ESTIMATES OF D. E. C. 's CONFIGURATION (**) 


Price estimated to oc sonx-w! at Jess than IBM 1ft00-360/44 configuration 



a particular processor primary control over a specified area of Operator Displays (The number of 

memory. devices is not known at this time) 


** The details of this configuration are superficial so that operations of 
the shared memory and PDP I/O channels is questionable. 
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H. CORRESPONDENCE AND ACTION RECORDS 

Due to the large amount of correspondence in the DIMAC area, only a 
small portion of what is felt to be significant correspondence in this 
area has been included at this time. 

The following is a listing of additional correspondence available at the 
MOL Project Group central file related to both the DIMAC and the 
Cape Kennedy OCALA effort. Copies may be obtained either by formal 
letter request to: 

IBM MOL Project Office 
Advanced Programs (SSC) 

Federal Systems Division 

9045 Lincoln Blvd. , Los Angeles 90045 

or by telephone request to: 

213 670-8350 Ext. 652 

I. DIMAC computer support requirements - Martin-Denver, Nov. 5, 1965. 

2. Assumed functions of DIMAC system from programming standpoint - 
R. Mossman, IBM, December 10, 1965. 

3. Trip Report regarding Martin-Denver checkout concept covering 
periods December 8 through 10, 1965 - G. Boruski, IBM/LA. 

4. Trip Report - MOL checkout system for Martin-Denver - Oct. 11, 1965 
W. Peavy, Washington Systems Center. 

5. OCALA study monitor program descriptive specification - Nov. 5, 1965, 
R. Blue/L. Perkins, IBM, Cape Kennedy. 

6. OCALA monitor notes - J. Hoerning - December 1, 1965. 

7. Conference notes on ETR computer study review held at Martin-Denver 
November 1, 1965. 

8. Weekly project OCALA status reports - Nov. 5 through Dec. 10, 1965, 
R. E. Blue, IBM/Cape Kennedy. 

9. Preliminary System Specification for the Design of a Monitor and 
Diagnostic Computer Complex for the Titan IIIC Vehicle, Feb. 1, 1966. 
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October 6, 1965 


TO: Mr. R. Winckler 

DENVER 

FROM: Mr. F. X. O'Rourke 

FSD 

HUNTSVILLE, ALABAMA 

SUBJECT: Comments on IBM-Martin Computer Implementation 

Concept for MOL Checkout 


1. General 

As a result of agreements between Mr. T.. Welch of WSC and Mr. 

J. Meadlock of IBM-FSD, Huntsville on September 29, 1965, the writer 
was assigned to evaluate and comment on existing details of the proposed 
IBM computer implementation concept satisfying postulated Martin-Denver 
requirements for MOL checkout and launch control functions. 

During this visit the writer discus’sed the problem with Mr. R. 

Winckler of IBM, Marketing Representative;. Mr. J. Stunkel, Systems 
Engineer; Mr. Robert Umbreit, Marketing Manager; as well as Mr. Kent 
Gunderson, Mr. Rod Ourada and Mr. Bryan Pennington, all of Martin- 
Denver. 

As a result of these conferences and by reviewing preliminary configur 
ation documentation (provided by Mr. Winckler), some basic conclusions were 
reached regarding the nature of the Martin requirements as proposed by Mr. 

K. Gunderson. 

It should be stressed that due to the short duration of the visit, these 
conclusions are preliminary and are noted here to provide a basic structure 
within which further system study may be initiated. 

2. Proposed Equipment Configuration 

Martin presently envisions a computer system to perform advisory 
and monitor functions only. The system requirement described by Martin 
personnel would not be a part of the countdown or launch control loop and 

or checked out through the computer system. 
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DENVER 

Their engineering view of the system includes a computer complex 
capable of monitoring telemetry data from both the vehicle and associated 
ground system as well as specific vehicle discretes. The proposed system 
would, through hardware and program control, perform limit comparisons 
on the telemetry data, and when out of tolerance conditions affecting the 
ability to launch the vehicle occur, suitably process .this information and 
transmit it to appropriate display consoles. The system, as configured, 
would have the capacity of monitoring from 400 to 3,000 analog quantities 
input to the computer configuration from T/M ground stations and discrete 
output equipment associated with the vehicle. 

\ 

There would be up to three display consoles in the proposed system, 
one console would be of a "Test Conductor Monitor" variety over which 
specific fault messages with little or no .troubleshooting data would be 
displayed. The other consoles would be of the test engineering (Trouble¬ 
shooting) variety which would display not only the fault but pertinent trouble¬ 
shooting and diagnostic data to allow further evaluation of the fault by the 
Test Engineers. 


Both "troubleshooting" consoles, as proposed, would have keyboard 
input facilities to the computer to allow recovery of certain specific parameter 
information held in computer core. The system further envisions the use of 
standard peripheral equipment found in existing launch control systems includin 
printers, graph display facilities, disk files, card read and punch facilities and 
tape recorders. A somewhat unique item of peripheral equipment proposed 
would be an IBM Microfilm File. In the application suggested, the central 
processor (IBM System/360) would not only display pertinent information to 
the three consoles upon malfunction detection but would also call up (under 
program control) microfilm file data related to the malfunction to provide 
maintenance personnel with pertinent troubleshooting data to assist in 
formulating remedial actions. This microfilm data could not only be called 
up under direct program control as determined by the error but could also be 
requested by the operator to supplement his initial data. 

Enclosure I of this document illustrates the general block level con¬ 
figuration of the proposed system which uses up to four 1800's feeding a 
master control processor implemented with a 360/44 system. 

• Martin-Denver personnel stressed that a basic ground rule of this 
system would be THAT NO ELEMENT OF THIS MONITOR AND DISPLAY 
SYSTEM WOULD EVER BE CONSIDERED LAUNCH CRITICAL. In this 
regard, no functions performed by this system would be of such a nature 
that their loss or omission would in any way hinder the launching of a vehicle. 
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Mr. R, Winckler -3- , October 6, 1965 

DENVER 

As proposed by Martin, the DIMAC system (Data Integration and 
Malfunction Analysis Computer) configuration is planned for utilization 
by all contractors to enhance the probability of "launch on time", "mission 
success", and "crew safety". The DIMAC system is envisioned by Martin as 
a powerful and flexible device capable of satisfying the individual contractor's 
computer requirements for simultaneous or individual usage. 

In summary, Martin assumes the system will be capable of isolating 
malfunctions, providing data computations, comparing actual limits and 
events versus theoretical pre-defined limits and events on a continuous 
CONSTANTLY UPDATED BASIS using both event and time criteria to update 
the limit evaluations. Enclosure I of this document further summarizes general 
requirements of the system as postulated by Martin. 

3. Conclusions and Comments 

From the data available to the writer from both Martin and IBM- 
Denver, the approach as postulated by K. Gunderson is very feasible and 
very conservative. It represents the state of Douglas checkout approximately 
two years ago and, if implemented correctly, could be of material assistance 
in streamlining launch countdown troubleshooting as well as vehicle checkout 
and validation tasks prior to the actual countdown. This system if developed 
would provide the launch complex with a readily accessible troubleshooting 
data source as well as a comprehensive, partially continuous monitor capability 
during both checkout and launch functions of the Titan vehicle. 

In this regard it is the writer's opinion that IBM should exercise great 
care in assuring that cognizant Martin and Air Force personnel are thoroughly 
aware of the basic constraints of the proposed computer configuration and that 
any expansion of the proposed system to include a capability of generating 
stimuli to the vehicle or acting in the direct launch countdown control loop 
would require significant modification of the overall system from both the 
hardware and programming standpoints. 

It is the writer's impression that personnel at Martin who were contacted 
in this effort were knowledgeable and fully aware of the ramifications of their 
proposal. However, it is felt that prior to further investigation IBM should 
ascertain the feeling of Martin management to the eventual implementation of 
this proposal and,if at all possible, the feelings of the Air Force in this regard. 

The concept, however, if developed affords an excellent entry for IBM 
into the checkout and control business associated with the Aerospace Industry. 

It would allow IBM to enter into the design and development of an Aerospace 
computer system that is external to the main control link of the vehicle. In 
this way IBM can gain very significant experience in the Aerospace Engineering 
problem without being immediately subjected to a critical spotlight in the event 
the system runs into unforeseen difficulties. IBM can then utilize this experience 
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DENVER 

to expand its computer systems efforts into supplying hardware systems 
directly in series with the launch control links associated with firing and 
checking out a vehicle based cn capability acquired in producing the Martin 
system. In the event that IBM as a Company desires to get-'a foothold in the 
Aerospace Industry for the neyt ten years, this type of system affords an 
excellent opportunity to do just that. 

In summary, the following list of comments and conclusions is 
presented for evaluation and consideration. 

1. The system being proposed by Martin-Denver is conservative 
and very feasible. 

2. The implementation configuration using I800 ! s working in con¬ 
junction with the 360/44 System seems feasible but requires a 
good deal more of detailed engineering study to provide engineer¬ 
ing assurance that the many details associated with data rate, 
comparison requirements, addressing requirements, special 
hardware, system interface, and expansion potential will not 
constrain the development of this system in such a way that the 
basic requirements of Martin could not be adequately satisfied. 



Due to the departure of this approach from the general approach 
presently recommended by Douglas and NASA, IBM must assure 


itself before going any farther that Martin management and Air 


Force personnel have approved the basic 
under stand the postulated ground rules of 


approach and thoroughly 
this type of a system. 


After this assessment has been made it is strongly recommended 
that a Systems Engineering team comprised of qualified engineer¬ 
ing and programming personnel from Huntsville and WSC form a 
system study team at Denver in conjunction with Systems Engineers 
thoroughly familiar with, the elements of the 1800 and 360 Systems. 
This group would study the proposed configuration from all aspects 
and in essence, define interface details associated with the computer 
configuration IBM should propose to Martin. 


5. Upon completion of this study and the associated documentation, 
the results should be carefully reviewed by design review teams 
at Huntsville, WSC and Denver. After this, a final proposed 
configuration should be drawn up and presented to cognizant 
Martin personnel for their opinion. 
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.Mr. R. Winckler -5- October 6, bb 

DENVER 

6 . It is apparent from comments made by personnel at Martin’ 
that they are not fully aware at this time of the size of the 
programming task they have undertaken. It is recommended 
that IBM discreetly and cautiously through Martin management 
increase their awareness of the programming task associated 
with implementing a system of this type. In this regard, it is 


insr ceteris assocratec wrtn imjremen-mg tne crcoosec commuter 
configuration. This should not be undertaken until IBM's 
approach and desir.es for this type of business have been 
thoroughly established and the general goals of the group de¬ 
fined. 


7. In the event this effort is implemented and IBM does provide 
360 and 1800's to Martin, it will be mandatory that IBM also 
provide a high level of associated Systems Engineering support. 
Martin seems fairly weak in overall engineering experience 
associated with digital computer implementation techniques, as 
well as the more complex and sophisticated programming 
requirements which must be considered when installing a system 
of this nature. 


8 . In the event this study does develop and data becomes available 
that indicates this should be a significant IBM effort, immediate 
steps should be taken to consolidate its development into one 
coordinated effort as soon as possible, inasmuch as dual efforts, 
no matter how small or well directed (i. e. , R. Blue's effort with 
field personnel at KSC), can pose serious problems of coordination 
and can effectively retard the overall progress of a complex effort 
of this nature by presenting IBM as two separate groups within 
one company. 


9. Prior to effecting any formal commitment, IBM must thoroughly 
investigate its ability to produce the required system on time 
and should carefully consider the requirements placed on the 
present production capability by this system in relation to existing 
IBM delivery commitments especially in the area of "1800" units. 


FXO:ht 

cc: J. Meadlock-IBM-Huntsville 

W. Peavy-IBM-WSC 
T. Welch-IBM-WSC 
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For i l.C operations a MMC provided, common u 
to enhance the probabilities of "LAUNCH ON 
an extremely powerful and flexible device, 
computer requirements on a simultaneous or 


ervice computer (DIMAC) will be utilized by nil contractors 
TIME”, "MIS .ION GUC-EGG," arid "CkEW G AFi’.TY”. DIMAC will be 
and will be capable of satisfying each individual contractors 
individual usenge. 


The [.'{MAC will utilize telemetry (PCM), and DISCRETE (MRS) data as its inputs, and will be capable of 
isolating malfunctions, providing data computations, comparing actual limits and events vs theoretical 
pre-do fined limits and events on a continuous basis, and providing appropriate displays to individual 
contractors^ (An assumption is made b j MMC that the individual contractors input data will contain the 
information which is necessary for the computer to provide these capabilities.) 


The f >1 lowing is a list of general and individual system requirements fox' the booster' vehicle, and is 
included as an example* of the tasks that MMC will accomplish with DIMAC. A comparison matrix is 
included also, as an example of the total control center OGE task vs capability. 

Gon era 1 Kequi rornents 

1. Malfunction analysis and isolation to the black 5 <:.x level for all. systems., 

2. Success criteria comparison in real time for subsystem checks, CUT and launch countdowns. 

3. Trend analysis of appropriate data on a veliicle/vehicle, test/test or short term basis, 

h. Provide DKG o« line tabulation of all discrete event changes. .) 

keqni r ements per Gystem 
1. Flight Controls 

A. Provide redundant and extended monitor cnnaMllty for VECOG checks, 
p. Provide capability for end to end testing of fee attitude control system. 

C. 



Provide par-all 1 monitoring of redundant systems. 
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p. 'Provide trend data for following Items: 


(l) Actuator response and positioning 
(?) Hydraulic pressure, level, and temp 
( ')) ( jy r o t e m/time 

(4) Gyro spin up and spin down time 
(b) Gyro output versus torquing stimulus 

b. Monitor pump motor total starts, arid the total run time. 

F. Evaluation guiduncopackage perfonaance. 

G. Monitor guidance input and offsets to the autopilot. 

?» Tracking and Flight Safety 

A. Monitor battery on line time. 

B. M'-ni tor 1 30CVIT operate time. 

G v Plot AGO voltage versus tine. , 

0. Moni tor nil bus v- j 1 taper.. 

K. Provide tr^nd data for following items: 

(l) Battery current/time profiles 
(?) All GOCVH and switch operate times 
(A) .'I f ( A operate times 

(4) AGC voltage 


w 
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:j. Prov i .\e i' 1 1 < !ii) f. i c or on • •eHiu.inl a mb i on t du'cko find print out..- 
Hot ivy; ton. cal II.ration plots and print 
V. Provide eonyuta tionnl capability for reducing data. (■ 
royu] t of having the cony* ‘ter, tie follow 5 ng addl tional capabi li t i es vrill be available. 
In flight went tor inp; and cc ; * tat 1 onal capability* 

: r> t f 11, lit and post toot data reduction and analysis, 
bir.pl etc uyt ten; stains (veld el'.-, GOR, and Mb) at any time. 

Aunriniwtra L ; \e services such as 

Procedure status and procedure writing 
Test soli .‘dulling and monitoring 
n tIvT •; r i M cal i a t)> won i tor i ng 

p, no J i a hi i i pY succo.-s/al tempts mo a i. to ring .and tabulation 
I,\, Configuration control 
Spares status 

> *.. Vabul - i«» support r-cnul raniouts for all testa 
h\. !.’ j work aid retest os t i m ■ tea 

1, Opnn iteirvi status and control 
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For LIC operations a MMC provided, common service computer (DIMAC) will be utilized by all contractors 
to enhance the probabilities of "LAUNCH ON TIME", "MIGdlON SUCCESS," and "GREW SAFETY". DIMAC will be 
an extremely powerful and flexible device, and will be capable of satisfying each individual contractors 
c< mputer requirements on a simultaneous or individual useage.. 

The DIMAC will utilize telemetry (PCM), and DISCRETE (DRS) data as its inputs, and will be capable of 
isolating malfunctions, providing data computations, comparing actual limits and events vs theoretical 
pre-Jefined limits and events on a continuous basis, and providing appropriate displays to individual 
contractors* (An assumption is made by MMC that the individual contractors input data will contain the 
information which is necessary for the computer tc provide these capabilities.) 

The fallowing is a list of general and individual system requirements for the booster vehicle, and is 
included as an example of the tasks that MMC will accomplish with DiHAC. A comparison matrix is 
included also, as an example of the total control center OGE task vs capability. 


Gone ra1 Requirements 

1. Malfunction analysis and isolation to the black box level for all systems* 

2. Success criteria comparison In real time for subsystem checks, CST and launch countdowns, 

3. Trend analysis of appropriate data on a vehicle/vehicle, test/test or short term basis. 

4. Provide DKG on line tabulation of all discrete event changes. 

Requi re ir.cn ts pe r System 

1. Flight Controls 


A. Provide 

redundant and extended 

monitor cusability 

for V’ECC 

>G checks. 

i‘ . Provide 

capability for end to ■ 

end testing <>f t- ** ■ 

11 t i 1 u>le 

control ny 

C, Provide 

jar all 1 monitoring of 

redundant systems. 
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P. Provide trend data for following items: 

(l) Actuator response and positioning 
(?) Hydraulic pressure, level, and temp 
(3) Gyro tem/t.ime 

(*0 Gyro spin up and spin down time 
(5) Gyro output versus torquing stimulus 


E. Monitor pump motor total starts, and the total run time. 

F. Evaluation guidanccpackage performance. 

G. Monitor guidance input and offsets to the autopilot. 

2» Tracking and Flight Safety 

A. Monitor battery on line time. 

B. Monitor oOCVtf operate time. 

C v Plot AGC voltage versus time,• , 

0. Monitor nil bus voltages. 

K. Provide tr^nd data for following items: 

(1) Battery curront/t5me profiles 
{?.) All GOGVU and switch operate times 
('>) 0 f< A opera I e times 

(*i) AGC voltage 


L 
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3. Propulsion 


\. Compute ac'uul .1 ■ xd durire; pro ant loading by ry rrclutine 1 :?v*7 condor, flow n:c*tor, tar.k 
en.li bra! ion, i:.r-.‘3oi;rt, aid temperature d»ta. 

y. Provide r.ar k t -re,r-.: , art1 t lo-.porstnro r odents in on; • *neerdng units. 

C. Monitor and t ):vvi .. c c iloul.sf.i ana on propellant tank temperaLuro„ 

P. ri.'ipedi t** cb-'cliout o f trur.otu.ee helium, nitrogen, and attitude control system. 

a. Provide * rend da: t. on follow 5 u.v ilons: 

(1 ) Tank pressure aru to::;; . r ' 

(~) Valve m--’ t n valve t i me ami position ■ ; “ * 

’ ■•) 'Mart eurir i J,;e temp: nature 

dlectricnl 

A. Monitor IT bus u :t.er.v vol tages. 

>. Honitor buttery on lino lime. 

Provide trend data on follov/iug items: 


(1) .la 11ery j- rr cn t/11me pro r 5 los 
(P) Ail .suite); :ud red rj operate times. 


\ 


3 In drumen tatior 

;V. Pro v id#* -fut-rii • t i e correct i-. >n of calibration data. 

*. pia./j.;-; data a>;d displays in ■•upir •mils, 

(■. Provide Jinit.. 'decks - u n»l JdlM duui •»■; a function of lime and event.. 
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D„ lYovide nutorautic or on demand ambient checka and print onto 
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l'lot system calibration plots and prist outs. ^ 

, .// . * * v V ‘ • 

F. Provide computational capability for reducing data. ( f' 

A a a result of having the computer, tie following additional capabilities will be available,, 

1. In flight monitoring and com u tat i onal capability. 

/) 

?. i o. t fli, lit and post test data reduction mid analysis. 

3. '.Vir.pl etc sjc ten. status (vehicle-, GOE, and Gib) at a ny time. 

1|. Administrative so rv i cos such us 

A. Procedure status and procedure writing 
B„ Tost sch-jduling and monitoring 
/ OV i’M<T critical path monitoring 

1). Pel lability succu. .s/at tempts monitoring and tabulation 
IV. Configuration control 

r. Spares status , 

G. Vabul-te support ro^uicements for all testa 
H„ Rework n-d retest cr-ti wtim 

I. Open iteina status and control 
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November 29, 1965 


TO: Distribution 

SUBJECT: Status of Martin-Denver DIMAC Effort (Report Two) 

ENCLOSURES: (a) Project OCALA Progress Report, 12 November, 1965 
(b) Background.Report, 5 November, 1965 - R. Winckler 

GENERAL 

1. This report outlines initial analysis and recommendations for IBM 
support effort of the two booster check-out projects in Denver. The Eastern 
Test Range (ETR) IBM - Martin - Aerospace - Air Force joint study,also termed 
OCALA, and the Data Interrogation and Malfunction Analysis Computer (DIMAC) 
presently being specified by Martin for inclusion in the Titan III blockhouse at 
Vandenberg AFB in support of the MOL launches. 

2. Discussions were held with Martin-Denver engineering, together with IBM 
Denver on November 23, 1965. Martin personnel contacted included: 

K. Gunderson - Senior Engineer, B. Pennington - Senior Engineer, J. Evans, 
Programmer, J. Hoerning - DIMAC Senior Programmer, R. C. Taylor - DIMAC 
Systems Engineer. IBM personnel were: D. Winckler and J. Stunkel. 

DIMAC STUDY 

1. The engineering and systems design effort by Martin associated with DIMAC 
is progressing rapidly and is in the final stages of definition at Martin. The 
Martin ILC Trade-Off Study Report X3-010, specifying Martin’s recommendations 
for an ILC System for installation at Denver and 'Vandenberg, has been submitted 
to the Air Force/Aerospace Group for approval, pending release of a formal RFP 
for this system around February, 1966. 

2. Rapport with Martin-Denver personnel is excellent and they seem anxious 
to work with IBM personnel in formulation and development of their check-out 
system. A copy of the ILC Trade-Off Report was informally transmitted to 

D. Winckler for analysis and comment. This report defines the general concept 
in detail and, after incorporation of the Air Force/Aerospace comments, will, 
in all probability, form the main body of the resultant RFP. Initial analysis 
of the content of this document clearly indicates they have incorporated the IBM 
proposed approach and have used quite a bit of data provided by IBM. 

3. The DIMAC System, which is an essentially passive monitor/diagnostic 
system., has progressed to such a point within the Martin Engineering structure 
any attempt to directly influence Martin to incorporate a more active check-out 
system (similar to the Douglas proposed concept) would almost certainly result 
in failure and might jeopardise our rapport with Martin at this time, as: 
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1) the Martin/Air Force contract concept is based 
upon using a proven booster with a proven launch and 
check-out facility involving a minimum of modification 
prior to delivery 

2) The MOL time schedule does not permit severe 
modifications in the Titan III launch procedure. 


3) Martin Engineering feels present launch equipment 
is proven and has categorically stated to Air Force any 
modification of this equipment would jeopardize both 
schedules and launch reliability. 

4) The Aerospace Systems Engineering Group will , in 
all probability, go along with the Martin check-out concept 
rather than place themselves in the position of being res¬ 
ponsible for Martin booster checkout. 

5) Martin Engineering personnel are, for the most part, 
opposed at this time to inserting a computer in the direct 
control link. They prefer to develop the safer approach of 
a passive monitor system until more operational data Is 
available from other projects on the feasibility of using a 
computer as the major control element in launch and check¬ 
out . 

Summary - DIMAC will perform complex analysis of countdown data in 
real-time which is not now possible, permitting more rapid 
recovery from hold. It will further provide a capability to 
analyze trends in an attempt to predict malfunctions prior to 
their occurrence, and generally should provide more 
information to meet ’’Launch On Time" criteria. 


This function is felt by the Air Force and Martin to be sufficiently important to 
justify the design and production of the DIMAC system. While the DIMAC has 
been justified on the above basis, as an initial entry point for computers into 
the Martin checkout philosophy, this in no way precludes eventual implementa¬ 
tion into the system of a complete control checkout loop. Martin Engineering 
is, in general, very interested in providing an open end to further employ the 
computer in performing more comprehensive checkout and control functions at 
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a later date. In this regard, any effort on IBM's part to implement and con¬ 
figure the DIMAC system should take into consideration the possibility of 
eventually incorporating more direct control functions without requiring a major 
modification to the initial passive DIMAC approach. 

During the meeting, it was stressed that the formulation of the DIMAC 
System, is proceeding rapidly. Since this effort is now well under way at Martin- 
Denver and has a high probability of Air Force approval, it is recommended that 
a pre-proposal study be immediately initiated at Martin-Denver to define system 
hardware configuration and software support requirements involved in producing 
this system. Preliminary estimates of the effort required to handle this proposal 
indicates a team of 5-7 qualified members will be necessary for a 2-month 
period to develop and document the concept that would give IBM a high prob¬ 
ability of obtaining the Martin computer check-out effort. 

ETR STUDY 

Further discussions specifically concerning the current ETR study effort in 
progress at Cape Kennedy brought out the following points: 

1) The effort is being directed and evaluated by Martin- 
Engineering who are responsible at present for final 
approval of all elements of the task. This is the same 
engineering group that is specifying and will select the 
DIMAC system. 

2) Martin, Aerospace and the Air Force will be very 
interested in performance of the study system at ETR. The 
study system, will monitor 3 launches of the Titan-III 
booster (same as MOL booster). These launches are 
scheduled for February, April and June of 1966. 

The system will monitor the data from the booster and 
subject it to limit checks (success criteria) developed 
at Martin-Denver, for the February launch. Fbr the April 
launch the capacity to locate malfunctions will be added. All 
planned study functions will be operational for the June 
launch. This includes the launch checkout capability and 
elaborate calibration procedures. 

3) Martin-Denver is currently manning the system 
analysis effort for the ETR study and has essentially 
completed initial analysis to the point of starting initial 
programming effort. 
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4) Martin-Denver is currently requesting an IBM 
programmer full-time to support the applications- 
program.rn.ing effort, being conducted at Denver in 
support of the ETR effort. This effort will be 
conducted in Denver until approximately January 15 
and then will move to the Cape through June 15. 

5) Martin feels sufficient data is not available at this 
time regarding the operational details of the SPADATS 
Monitor to allow their programming effort to begin 

at Martin-Denver. In this regard, a meeting is set for 
December 1, 1965, where IBM programming personnel 
are scheduled to present the details of the existing 
SPADATS Monitor program to Martin programmers to 
allow them to initiate the applications-programming 
effort. 

6) Since Martin-Denver is controlling the overall 
engineering management of the ETR, K. Gunderson felt 
it very desirable that IBM have a full-time systems 
engineer available from now until the first of January 
at Denver to handle the overall engineering coordination 
of the task between Denver and Cape Kennedy. 
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SUMMARY OF BASIC CONCLUSIONS 


1. The ETR effort at Cape Kennedy and the DIMAC effort at Martin-Denver 
are two highly interrelated but separate tasks, both being developed simul¬ 
taneously. 

2. The outcome of-the ETR effort will have a significant influence on the 
IBM posture in the MOL effort since any results will most certainly-be inter¬ 
preted by Martin and Aerospace as a reflection of IBM's ability to perform in 
this area. 

3. An RFP for the DIMAC system will be issued in January, 1966. 

4. The RFP will call for installation of the hardware in Denver in the fall 
of 1966. The system would be connected to the Denver check-out system and 
the total system developed for VAFB. The VAFB system would be installed in 
June of 1967. 

5. It is highly probable that the Air Force will approve the DIMAC approach 
with only a minimum of modification. 

6. Martin is completely sold on the passive role of the computer in the launch 
check-out of the Titan booster at this time. It being an ideal way to initally 
insert a computer into the system without upsetting those people fend the Air 
Force)not yet convinced of its value, as well as being a very useful 
method of increasing their'launch on time 1 score. 

7. The ETR study will be closely controlled by Martin-Denver personnel. 

As presently implemented, it requires further support on the part of IBM at 
Denver, especially from, the standpoint of programming help, as well as systems 
engineering management help to insure that the program is carried out 
successfully. 

8. Under present schedules the ETR effort is actively in check-out early in 
January. Unless more careful attention is paid to the coordination of the Denver 
and Cape effort and more help provided,there is a high probability the present 
schedules will not be met. 

9. If IBM submits a proposal on the DIMAC system, great care must be 
taken in configuring the system, in such a way that eventual expansion of the 
computer role in check-out function can be added without a major modification 
in the basic system.. 


Section 5.1 


Page H/22 
12/20/65 



IBM CONFIDENTIAL 


- 6 - 

SUMMARY OF INITIAL RECOMMENDATIONS 


1. Increased IBM support should be provided to the ETR study to insure its 
success. This should take the initial form of: 

' a) a coordinated engineering management approach 
(possibly centered at Denver). 

b) the assignment of a full-time senior programmer 
to work with Martin-Denver at Denver on the 
application programming effort and transfer during 
the check-out of this effort to Cape Kennedy. 

c) the provision of a full-time senior systems 
engineer to maintain the necessary engineering and 
management liaison with Martin-Denver and Cape 
personnel. 

2. A pre-proposal team should be assembled immediately to start the con¬ 
figuration of the DIMAC system, since almost all the engineering data required is 
now available and in the hands of Martin-Denver personnel. This team should, 
as a minimum., include one senior engineer experienced in vehicle check-out 
systems, one senior programmer, one engineer familiar with the 1800 system 
and an additional engineer (possibly part-time) familiar: with the 360/44 system 
plus,representation on a systems engineering basis from WSC. 

3. Steps should be taken to insure that the presently scheduled December 1 
meeting to technically describe the SPADATS monitor system facilities is of 
technical value to Martin personnel. 

4. A careful analysis of the SPADATS monitor program should be accomplished 
to insure that it indeed has the capability to meet the requirements of the ETR 
study. It is almost certain the some programming modification will be required 

at this time. 

5. The problem of getting Martin to expand the computer's role in the booster 
check-out from a completely passive to an active system must be handled, very 
carefully over a long period of time. Provisions can be considered and included 
in our design to permit this function to be implemented relatively easy later. 

This approach would be very favorably received at Martin-Denver. 


FXO'Rrjh 
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Submitted by: 



R. Winckler 
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/ PROVIDE OVER-ALL PROGRAM DIRECTIONS'M>' 

,x.. V , ^ v .. ^ . . . . ^ . . 

/ . DEVELOP PR OGRAM PLAN ' : ’ * 




/ COORDINATE EFFORTS OF ALL PARTICIPATING AGENCIES 

MC/DENVER A. ’ ; 

/ ESTABLISH SYSTEM ANALYSIS CRITERIA 3 
/ ESTABLISH TREND ANALYSIS AND DATA REDUCTION CRITERIA 
/ ASSIST IBM V/ITH PROGRAMMING DEVELOPMENT A 

.XSM . , . - . ......... . ; ' V ' 

/ ASSIST MC IN DEVELOPMENT OF SYSTEM CRITERIA 
/ DEVELOP DETAILED PROGRAMING 3 
/ MONITOR LAUNCH OF VEHICLE #11, 12 AND 13 

6555th ATW/AEROSPACE ETRO 

/ MONITOR ESTABLISHMENT OF SYSTEM CRITERIA 
/ PROVIDE DIRECTION ON PROGRAMMING DEVELOPMENT 
/ PROVIDE DIRECTION ON OPERATIONS PHASE 
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ROM COSTS^ 2 ^ 

M&£€M >: " •• 

/ . INTERFACE CABLING $ 20,000 

/ IN-LINE COMPARATORS 20,000 

/ ENGINEERING SUPPORT 80,000 

$120,000 

IBM 

/ COMPARATOR $ 20 , 000 *** 

SUB CHANNELS 

TOTAL COST $140,000, 

(1) MAY BE POSSIBLE TO NEGOTIATE TOTAL PRICE TO $100, 000. 

(2| COSTS INCLUDE: 

/ . INSTALLATION AND CHECKOUT 

/ TWO ON-LINE COMPARATORS FOR CONTINUOUS FUNCTION 

MONITORING 

/ INTERFACE HARDWARE AND ENGINEERING 

/ SYSTEM ANALYSTS AND PROGRAMMERS 
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BACKGROUND 

© UTILIZATION OF ON-LINE COMPUTER FOR MALFUNCTION ANALYSIS 
DESIRABLE FOR ILC 

/ PRELIMINARY SYSTEMS DEFINITION UNDER STUDY BY MARTIN COMPANY 

/ YIELDS RAPID MALFUNCTION LSOIATION AND ANALYSIS WHICH RESULTS 
IN HIGHER LAUNCH CONFIDENCE 

O FEASIBILITY DEMONSTRATION CAN AND SHOULD BE ACCOMPLISHED AT ETR 

/ IBM SUBMITTED UNSOLICITED NO COST PROPOSAL 

© INSTALL 7044 COMPUTER AND PERIPHERAL EQUIPMENT AT ETR 

/ RAPID DATA REDUCTION AND LIMITED MALFUNCTION 

ANALYSIS 

/ SUCCESS CRITERIA COMPARISON 

/ TREND ANALYSIS OF DATA 

/ MARTIN COMPANY SUBMITTED UNSOLICITED ALTERNATE PROPOSAL 
TO. WORK WITH IBM 

e PROVIDE CRITERIA AND ANALYSIS METHODOLOGY 

g ADD IN-LINE COMPARATORS 

/ INCREASES COMPUTER CAPABILITY 




Page H/28 
12/20/65 



OBJECTIVES OF FEASIBILITY STUDY A't ETR 

DEMONSTRATE EFFECTIVENESS OF COMPUTER UTILIZATION FOR 
MANNED SYSTEMS 

DEMONSTRATE FEASIBILITY OF DETAILED RAPID MALFUNCTION ANALYSIS 
/ INCREASE CONTINUOUS DATA EVALUATION 

/ DIAGNOSTIC CAPABILITY 


PERMITS DATA FAMILIARITY DURING ALL TESTING PERIODS 
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CONFIGURATION FOR ETR FEASIBILITY STUDY 


/ 
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PROPOSED CONFIGURATION AT ILC FOR MANNED SYSTEM 
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COMPUTER MODES DURING CHECKOUT AND LAUNCH OPERATION 

£>l { /2. > c'-v- 7 " 5 c •- s <- LT s s9S2 *T~ /£>/ 

3INED SYSTEMS TEST \ \ 

.fcvP>^ Veh. 11 Veh. 1 

\P FEB. ‘APRXI 




COMBINED SYSTEMS TEST 


Veh. 12 Veh. 13 
APRIL JUNE 


/ AMBIENT CHECKS 



© ■ 

IN -LIMIT CHECKS OF AIRBORNE 

SENSORS 

70% 

100% 

tr* 

o 

o 

D ftS 

© 

CHECKOUT OF CMG GO-NO/GO 
INDICATORS 

1007b 

100% 

>—* 

o 

o 

o' 4 


G 

COMPARISON OF REAL-TIME CALI¬ 
BRATION VS. PAST PERFORMANCE 

... 

100% 
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CP* 
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PREDICTION OF PROBABLE LIMIT 
DECAYS . 

20% 

6 0 % 

100% 



/ TANK TOP PRESSURES 
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DETECTION OF A MALFUNCTION 
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* 100% 

100%) 


© 

AUTOMATIC READOUT OF DATA RE¬ 
QUIRED FOR MALFUNCTION ANALYSIS 
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o 
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© 

STORE TEST RESULTS FOR LATER 
COMPARISON 

100% 

100% 

o^ 
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PREDICTION OF LIMIT DECAY 
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100% 
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COMPUTER MODES DURING CHECKOUT AND LAUNCH OPERATION 

(CONTINUED) 

Veh. 11 Veh. IE 

FEB. . APRIL 


/ COUNTDOWN/CCUNTUP 

© COMPARISON OF DRS EVENTS VS. 

SUCCESS CRITERIA * 100% 100% 

/ AUTOMATIC READOUT OF DATA 

FOR MALFUNCTION ANALYSIS 

© IN-LIMITS CHECK OF AIRBORNE SEN¬ 
SORS VS. SUCCESS CRITERIA 100% 100% 

/ PRINT-OUT DEVIATIONS FROM 

NORM 

© TRANSIENT CHECK OF LIMITED AIR¬ 
BORNE SENSORS VS. SUCCESS CRITERIA---- 50% 

/ PRINT-OUT DEVIATIONS FROM 

NORM 

© (; ANALYZE HOLDS AND KILLS 40% 80% 

© STORE DATA FOR LATER COMPARISON 100% . 100% 

LAUNCH OPERATIONS 
/ COUNTDOWN 

© PROPELLANT LOADING; T-l DAY 

/ MONITOR SYSTEM PERFORM¬ 
ANCE 100% 100% 

/ PROVIDE MALFUNCTION - 80% 100% 

ANALYSIS OF PROBLEM AREAS 


Veh. 13 
JUNE 


100 % 


10054 


10054 


10055 

100 % 


100 % 

100 % 




COMPUTE? MODES DURING CHECKOUT AND LAUNCH OPERATION 

(CONTINUED) 
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Veh. 12 
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JUNE 

o 

T- 

T- 

COUNT; AT SELECTED TIME FROM 

195 MIN. TO T-31 SEC. 
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AMBIENT CHECKS 
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o 

»_<•> 

© 

PRESSURIZATION; T-160 MIN. T T-31 SEC. 





/ 

ANALYZE TREND DATA 

60% 

100% 

100% 



© PREDICT TIME TO OUT-OF- 

LIMIT CONDITION 




o 

• YEGGS; T-55 MINS. 





/ 

SAME AS CSX CHECK 

50% 

100% 

100% 

o 

TERMINAL COUNT; T-31 SEC. TO LAUNCH 





/ 

MONITOR REAL-TIME PERFORMANCE 
(DRS & CMG) VS. SUCCESS CRITERIA. 

100% 
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• sfV 

100% 


/ 

AUTOMATIC PRINT-OUT OF ANY HOLD 
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. 
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o 
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100% 


/ 

AUTOMATIC PRINT-OUT OF DATA RE¬ 
QUIRED FOR MALFUNCTION ANALYSIS 

20% 

60% 

*— • 

o 

o 

•tR 

o 

LAUNCH PHASE 





/ 

R E C OR D T. M. DAT A FOR R A PID PR IN T 

OUT CRITERIA 

100% 

100% 

100% 


IBM CONFIDE 



Page B/34 
12/20/65 



SCHEDULE 
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subject Trip Report - Computer for ETR Meeting 
at Cocoa Beach on 25-26 October 1965 
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The meeting convened to determine organizational setup, ground rules and how 
the system would be configured. The organizational block diagram is shown in 
attached Figure 1. A more detailed schedule is shown in Figure 2, 


The following ground rules were established: 

1. The central points of contact are established as follows: 


Organization 

Name 

Address 

Phone 

SSD 

Capt. N. North 

SSBTA, Los Angeles 

643-1402 

IBM 

B. Blue 

7900 N. Astronaut Ave. 

Cape Canaveral, Fla. 

784-9622 

Aerospace, 

El Segundo 

J. Kimose 

2400 E. El Segundo Blvd. 

* El Segundo, Calif. (B/2034) 

648-5536 

Aerospace, 
ETRO 

W. Dillon 

Box 4007, 624A Program 
Patrick Air Force Base, Fla. 

853-5695 

6555th ATW 

D. Jacobs 

6555th, DWBS 

PAFB, Fla. 

853-9071 

MC, Denver 

A. Ash 

Box 179, Denver, Colo. 

Mail Station E 456 

794-5211, 
x: 4595 

MC, ETRO 

D. Mackey 




2. SSD/Aerospace shall serve as Program managers. MC/Denver shall 

serve as integrator for all efforts pertaining to the study def men - 

tation, installation, and final study report upon completion of the program. The 
final report shall include the inputs of each agency participating in the study. 
Copies of the report will be provided to the central points of contact. 

3. Aerospace will provide two programmers and one systems analyst.' 

One programmer from ETR and one programmer from El Segundo. The systems 
analyst will be made up of several people part time. 

4. IBM will provide the computer, computer, maintenance, two program¬ 
mers and a systems analyst. I -G v.c / • ; 

4 - .. 

5. MC/Denver will provide the in-channel comparators, interface adap¬ 
ters, fifty (50) hours of 7044 computer time, 2 programmers and 3 system 
analysts. MC/Denver will provide the systems analysts-in Denver until 1 JdbLA 
1966, when the major effort will be transferred to ETR. For the remainder of 
the study MC/Denver and MC/Canaveral will jointly provide systems analysts. 
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6. MC/Denver will retain configuration control for all software and hard¬ 
ware. They will document the study tasks by the normal FEDCP route using 
sketch engineering and modifications. These will initially be maintained in a ■ 
single document and a copy provided to each of-the single points of contact. 

Aa/z> , 

7. The computer will be installed in the Instrumentation Room in the 
Vertical Integration Building (VIB). IBM will furnish detailed computer require¬ 
ments to MC/Denver for its installation by 1 November 1965, 

8. The study will encompass as a guide the briefing document entitled, 
"Titan III On-Line Computer Feasibility Study," dated 20 September 1965. (All 
interested parties have been furnished a copy. ) 

9. All agreements will be documented by the originator and distribution 
'made to the central points of contact. These shall include telephone calls, 
TWX's, and meetings. 

A meeting was scheduled for the week of 1 November 1965, to define to the work¬ 
ing level people the systems program definition, data format and data flow. It 
will work within the established ground rules and work out the details to imple¬ 
ment the study. IBM will define and explain their monitor program. The pro¬ 
grammers and analysts will decide on the most efficient format Sot data transfer 
between these working groups. 

JJK: jm 

Attachments: Figure 1 
Figure 2 

cc: Lt/Col F. Kniss, SSBD 

Maj. L. Daniels, SSBT 
Capt. N. North, SSBT 

D. Baxter 
j L. Chevlin 

W. Dillon, ETR- 
T. Hanrahan, ETR 
W. Hodson 
S. Lafazan 
W. Lyons 
D. Miller 
R. Schack 
A'. Shier 
R. Whalen 
Central Files 
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WORK STATEMENT 


The purpose of this project is to gain experience in the use of an 
on-line digital computer for data analysis during Systems Tests 
and Countdown of a research launch vehicle. These tests are to 
establish guide lines, for developing a system concept, hardware 
design, computer programming, manpower and cost requirements 
for an operational OCALA system. 

An available computer with more than adequate capacity to meet 
the presently anticipated requirements will be connected to the 
existing Titan III Ground Support Equipment (GSE) to conduct the 
tests. The existing Titan III test and data analysis procedures 
will be evaluated to select representative tasks which can be ex¬ 
pected to exercise the system design parameters. These tasks 
will be converted to computer based analysis, programmed and 
tested under simulated conditions. A Monitor program will be 
developed to sequence task execution according to time, events 
and operator control. When' this program has been thoroughly 
tested, the on-line connections to the GSE will be made and opera¬ 
tional tests will be conducted. Operating experience will be 
evaluated in terms of the original system design criteria. 
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EQUIPMENT 


The Ground Support ’Equipment (GSE) in the Instrumentation 
Room of the VIB provides access to all of the signals .used in 
system test evaluations. An IBM 7044 Data Processing System 
will be tied into the existing GSE without interfering with the 
current use of the equipment. The computer configuration and 
GSE interfaces are described in the following. 

COMPUTER 

The IBM 7044 Data Processing System is a general purpose 
binary computer that has been adapted to on-line data processing 
by the addition of the 7288 Data Communications Channel. The 
computer has a 37-bit word and a basic core storage cycle of 
2.0 microseconds. Processing and input/output operation is 
overlapped. The configuration required for the study (Figure 
1) includes a 1301 Disk Storage Unit, two 729V Magnetic Tape 
Units, a 600 line-per-minute 1403 Printer and a 1402 Card Read 
Punch. A physical installation plan for the VIB is shown in 
Figure 2. A complete list of the 7044 system units is given in 
Table 1. 

GSE/COMPUTER INTERFACES 

Four connections must be made from the GSE to the computer 
to acquire the data necessary for real-time and postflight (test) 
analysis. Telemetry data from two of the ASTRODATA PCM 
ground stations will be fed to two 7288 subchannels. Event data 
will be obtained from the slave Data Recording Set (DRS) as it 
is recorded on tape. Range Time will be obtained from the slave 
DRS time decoder. 

PCM Interface 

Data from the PCM links will be obtained from the Data Storage 
Registers (DSR) in the Astrodata Ground Stations in the Instru¬ 
mentation Room*. Eight bit syllables will be transferred as they 
are assembled in the DSR (Figure 3) to a variable character in¬ 
put (VCI) subchannel adapter in the 7288. The function of this 
subchannel is to provide controls and data buffering to assemble 
four syllables from the telemetry link into one 36-bit computer 
word. The subchannel will gate the entire 960 syllables from a 
major frame into a block of computer storage starting with the 
first syllable after the main frame sync pulse is received. It 
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will transfer the next, major frame into an alternate storage 
block and then return to the first block to provide a continuous 
reading of all data from one PCM link at a time. The syllable- 
sync timing pulses from,the Accumulator/Decommutator will 
cause the subchannel to store each syllable in its input register. 
After four syllables are stored the subchannel control requests 
a computer storage cycle. 

DRS Events 


The DRS writes a seven bit parity checked character on a com¬ 
puter compatible magnetic tape. The output to the tape write 
amplifiers will also be transferred to a variable character input 
subchannel where six 6-bit characters will be stored per 36-bit 
word (Figure 3). The 62.5kc clock signal from the DRS will 
cause a character to be shifted into the subchannel input register 
The tape start signal from the DRS will signal the computer that 
an event has taken place. 

Time Code 


The DRS contains a time decoder chassis which decodes the 
range time code into hours, minutes, seconds and hundredths of 
seconds. The 26 bits required to represent time to the nearest 
10 milliseconds will be transferred in parallel to a Parallel Jnput 
Subchannel in the Subchannel Adapter Unit. A time word will be 
stored by the computer each time a main frame sync pulse is re¬ 
ceived from either PCM ground station. These connections require 
engineering modifications in two Astro data Ground Stations and the 
slave DRS. The 7288 will not generate signals that interfere with 
the normal use of this GSE. 

In Channel Compare 

The computer will maintain a current table of data limits in core 
storage for all PCM syllables. These limits will be transferred to 
a hardware comparator in the PCM interface equipment thru a variable 
character'output (VCO) subchannel. Each syllable will be compared 
against the high and low limits as it is transmitted to the VCI. If it 
is outside the set limits a bit will be placed in the 9th bit position of 
the syllable storage location. An out of limits interrupt will also be 
signaled to the VCO. The output limit data and input data stream will 
be synchronized by means of the main frame sync pulse. 


O'. 
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TABLE I 


Machine Model/ 


Type 

Feature 

Description 

7107 

t* • 

3 

#3880 

#4428 

#7498 

#1845 

#1846 

Processing Unit 

Extended Performance 

Floating Point Arithmetic^ Single Precision 
Storage Clock - Interval Timer 

1st 7904 Channel Attachment 

Two Additional 7904 Channel Attachments 

1414 

4 

#6025 

#7680 

#7681 

I/O Sunchronizer for Card R/P and Printer 
R.ead and Punch Col. Binary 

Synch. Storage - printer 

Additional Synch. Storage - Printer 

1414 

001 

I/O Synchronizer for Magnetic Tape 

1402 

002 

Card Read Punch 

1403 

002 

Printer 

7904 

002 

#1074 

Data Channel (2) 

Control Adapter for File 

1301 

001 

Disk Storage 

7631 

002 

File Control 

729 

OGS 

Two Magnetic Tape Units 
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November 5, 1965 
DENVER 


Denver Branch Office Support of IBM-Martia-Aerospace Corporation - 
Air Force Jal&t Study 


Mr. R. M. Umbreit 
Marketing Manager 
D ENVER 


On November let the subject study was begun with the participants 
meeting in Denver. 


Original Study Background: 


This study was first conceived at Cape Kennedy between an 
IBM SDD Representative |Robert Blue) and the Air Force Test 
Wing of SSD (Space Systems Divio Ion). The study was to prove 
the value of a computer La the real-time monitoring of the launch 
countdown of space boosters. The study was to specifically be us* 
to monitor two Titan 111 C ;irings In February and April, 1966. 


IBM hoped to gain new insight tab 
systenij, both hardware and ooftw; 
more intelligently in this large bs 
The Air Force saw In the study a 
same knowledge. They expect Chi 


$ the requirements oi such a 
iro 3 to permit it to compete 
£ intensely competitive market 
coot justifiable way to gain the 
it the computer uses in this wa 


V» 


will provide huge savings through minimising the tremendously 
expensive time it takes to check out and launch a complex space 


booster. 


IBM, (FRO-SDD) initially proposed to support this study with two 
programmers for six months and a rent free IBM 7044-7266 System 
for four months. The Martin Company (Eastern Test Range OF ice • 
ETRO), the Aerospace Company fSTRO) and the Air Force Test 
Wing (located at C pe Kennedy) all agreed to provide support - ii 
the study were approved. Ail of these Florida based groups report 
directly or indirectly to Martin*o customer fin Dos Angeles). The 
Air Force’s Space System Division (SSD) and their '‘consultants’' 
the Aerospace Corporation, ft Is the combination of these latter 
two that would have to approve the study. 
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IJLC Study Contract: 


At the same time that chi a joint 


. ,v v . J, r 


a proposed 


Marti© Company in Denver received a cbsdy contract from BSD/ 
Aerospace to design the ground suppers facility {Integrated Jbaunch 
Campion or IILC) to bo used to support the- launch of Titan 211-C's 
in the manned orbital laboratory {Li G 14 , 2i was for facilities such 
as this that IBM hoped to gala o efficient taaowlodgo through the 
study to enable it to sell use of IBM computing sysiemo. 


Conflict of Studies: 


The joint study proposed is Florida was to run from October, j 96b 
through April, 1966. To moot Bio ostahllobod MOI* schedule, the 
IJLC must be defined and hardware ordered by February, 1966. 


Martin/Denver (M/D), though cognisant of the joint study proposal, 
refused initially to participate. They felt that the study was 
inadequately supported to accompli oh its goals. Not only was there 
too little time allotted and too lev? people* assigned, but there was 
no provision for needed system support to define what the computer 
was. to monitor. The needed system support was only available 
from M/D systems engineering. M/D was also concerned that if 
the study failed, it would reflect negatively bach os their concept 
©f using a computer in IJLC proposal. 


foiat Study Be solution 

Several factors combined at this time {September! to convince 
all parties concerned that a study should be conducted, but on 
a differ eat basis than originally conceived. The study should be 
a prototypo of M/D l o IJLC approach. It should not only prove the 
value of a computer in this application but it should specifically 
prove that the way M/.D proposed to use a computer in IJLC was 
valuable and possible. 
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To acMevo this goal, the study muct be* 
engineers. This has all aco boo a agre< 
off on this basis. 


signed by M / D sy s tern s 
;o end the study is 


All of £h© participant to have gained from this modified direction. 

M/D ha a the opportunity to prove its IJLC approach to its customer. 
SSJD/Aerospace will bo able* to dcq this proof before they are asked 
to buy it. IBM has probably gained the moot of all. We are not 
only going to loam about 'checkout 1 , we 1 !! be involved directly 
la the development of the specifications for TLC and working 
directly with those who will select the vendor to supply the computin 
system. 

Conduct of the New Joint Stuck?: 


Ac mentioned above, the study will bo conducted just as any other 
Martin project is. SSD/Aerospace will approve and oversee the 
work. 


D- will control too design and development and oversea 

> 

its implementation. The implementation will begin at Cape Kennedy 
when fcho 7044 is installed January i. At that time SSD {ETRO}, 
Aeroopac© Corporation and Martin Company Cape Kennedy, 

personnel will assume control of the implementation. 

Study Organisation - Request for Branch Office S 8 B„ Support 

The study Is presently staffed as follows: 

Systems Analysis 

3 M/D Persons 


1 

$ 


IBM 
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Mr. R. M. 


- 4 - 


Application Programming 

1 M / D Program rn Q r 

i Aerospace L. A c Programmer 

i Aerospace E. T*R«0« Programmer 

oC* 

Monitor Programming 

Z IBM (FRO - Cape Kennedy} Programmers 

1 M/D Programmer 

OOP 

Hardware Coordination 


1 

IBM 

(Blue) 

Computing 

System 

i 

M/D 

Special 

Hardware a 

nd Interfaces 


W. 3 

. Gibson io 

working on 

providing FSD systems man 


from 

Huntsville 

to utilise an 

,d promote IBM experience in 


check out. 



1 propose that we supply a minimum 
IBM Systems Engineer frord the Bra 
in applications programming. .This 
to gain the local experience neceooa: 
Martin/Denver IBM systems for the 


C- one asp 
nch Office 

3 ti'i Cd 4 . Ci tc cf C 

y so 


ecially-c om n e 
to participate 
time and pioc 
a us to sell to 


tent 

e 


«*> 


Unde r s tand W. B 
familiar with the 


. Gibson has approval for 
real-time monitor that is 


an additional nun 
to be used in the 
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Study Schedule and -Location 


Preliminary targets call for some on-line monitoring of a Titan 
III C launch in February, 1966, Additional capabilities would be 
operational by an April launch. All facilities planned tor the study 
would be used to support the launch scheduled for June* {IBM has 
agreed to extend the study through June.) Following this, M/D will 
report the findings of the study to BSD/ Aero-space. 


The study will be chiefly located la Denver until the computing system 
Is installed at the “Cape” January l 9 1966. Systems Analysis will 
be performed by M/D personnel in Denver and supported by Blue at 
Kennedy after January 1. Applications programming would be done 
in Denver until January I, at which time It would move to the Cape. 
Monitor programming will be done at the Cape by IBM with liaison 
provided to Denver applications programmers. 

Belated Background Data 


M/D’s current IJ6C concept is an extension of the functions to be 
performed in the joint study with the 7G4L, This calls for the 
computer to be a passive or “non launch critical” element in the 
system. It will monitor all events and provide valuable information 
regarding the status of the countdown. Its most Important function 
will be to analyze and locate malfunctions so that they can be corrected 
with a minimum delay. Is will not issue stimulus to She booster. 

This will be done by special equipments in the coanner that has proven 
satisfactory for ail Titan launches to date. 


The fact that the computer is not being proposed to perform this 
last function has opened their proposal ho outside criticism and 
concern* Their approach io c. conservative one. It is safe and 
it can be. implemented In the time available* Nevertheless, it is 
not the approach being taken by NASA’s Saturn Project* There, 
the computer is performing all launch checkout functions. Specifics, 
this includes “closing the loop” by having the computer issue the 
commands to the booster during the count, as well as monitor the 
systems response. . This additional function provides flexibility that 
is considered by many to be particularly valuable. 


ay, 
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Mr. R. M. Umbreit 


November 


1965 


Those who support the more sophistics ted (NASA) approach include 
the MOL capsule contractor* Douglas Aircraft, and some of their 
contacts within SSD and the Aerospace Corporation. It is Douglas's 
plan to perform their capsule checkout completely by computer. 


should serve both contr; 


needed to be any chaa 
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attempt 
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approaches. (It is still likely* however, that Douglas* capsule 
will he monitored by Martin *3 ground equipment as well as by 
Douglas. Martin's monitor will perform a more complete status 
check-) 


Competition 


The M/D 1L.C study is now completing its first phase, Martin is 
about to submit Its report of how it Intends to launch the MOL. 

During the first phase most computer manufacturers were con¬ 
tacted and invited to submit recommendations and/or proposals 
to fit the application. Serious solutions were presented by Digital 
Equipment, Burroughs* G, E* and IBM. M/D is known to be 
pleased with D. E, C. and IBM's solution and are essentially using 
them as reference systems in their report. 

Our solution includes one System/360 Model 44 interconnected to 
four "front end" 1800 Systems. B. E. C* presented an attractive 
package of a PDF 6 and 4 PDF ?*o - all sharing a common memory, 
Further, the common memory can be partitioned to specify different! 
processor priorities In different blocks qf storage. 
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The noisfc step will be 1 for the A It Force to approve of the Phase I 
report. Then M/D will prepare an RFP and select the vendor. 
This was to have been accomplished prior to February 15th to 
permit hardware Installation in Denver by September 1966. The 
new joint study could affect this schedule. Much can be done on 
the 7044 that was to be done on the system in Denver between 
September 1966 and July 1967. 

//ot/ 

The IDO would be operational at Vandenberg by Faip^-of 1967. The 
system at Denver might be transferred to Vandcaberg but more 
likely an additional system would be installed there. The third 
possible system would'be to support other Titan 111 C launches at 
Cape Kennedy. 

IBM Order Status 

The system which we presented amounts to about $40, 000 points 
or $2, 000, 000 purchase. The potential exists for as many as 
three of these systems. 

To establish a delivery schedule for bidding purposes we entered 
orders for five System/360* s ([Model 44 3 s) and five 1800 Systems. 
The extra 44*a were ordered G.G tpo£2 0 ibiC G110 J oi 3 for 1800*2 

in case of either capacity or delivery problems. 


Shipping, dates established were for one Model 44 in late August' 
1966 and four for late September 1966 and mid 1967 for the 1800*3. 
To present the most attractive proposal wo should be able to deliver 
two 1800 Systems with the August Model 44. (Seems we should be 
able to swap circuit production between the Model 44 and the 1800.) 


To meet any special hardware requirements of these systems we 
hope to be able to call yrpon F. S. D. We don't expect much help 
from S. D, D, 
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DISTRIBUTION: Attendees, 

W. B. Gibson, 

J. J. Selfridge, 
Project Notebook. 


IBM CONFIDENT 


Report on Meeting November 2 9, 1965 
concerning. Martin-Denver Checkout 
_System__ 


This meeting was attended by the people listed on the attached roster The meeting 
discussed the situation, problems, and alternatives concerning the Martin- 
Denver Checkout System. "DIMAC" and the effort at Cape Kennedy using the 7 044- 
7288 headed by R. Blue. The agenda of the meeting is also listed in the attachment. 

Many of the questions could not be resolved at the meeting but certain conclusions 
were reached and a plan of action evolved. 

Conclusions: 

1. Since both DIMAC and the 7 044-72'88 (ETR) study at Cape Kennedy 

are operating under the direction of the same Martin System. Team, as much as 
possible should be done to further the ETR study. In this view it was felt 
desirable if, at all possible, to supply a programmer from IBM to work with the 
Martin personnel at Denver, working on the object programs for the ETR study. 
He should provide the interface knowledge for the "SPADATS" monitor and the 
object programs and in actual writing of object programs with the Martin people. 

It would seem best at the time that he report to R. Blue although assigned at 
Denver until January 15, 1966. When the Martin group moves to Florida In 
January a decision can be made whether to continue the programmer or with¬ 
draw him. in favor of phasing other of B. Blue's people into the task. 


2. A concerted effort should be mounted to get the best proposal for the 

"DIMAC" R. F. P. which is expected in January or February, 1966. This system 
will probably result in 40, 000 points of business. Since we have good relations 
with the Martin personnel and advance information about the system requirements, 
we appear to be in a good bidding position. 


The plan of action is as follows: 

1. Four people will spend the remaining portion of the 
week (November 30 - December 3) at Denver to analyze 
Martin requirements, proposal requirements, and 
marketing strategy. 


2. Prepare a report documentary this study effort and 
recommendations, including: 

1, Personnel required, 

2, Target date schedules, 

3, Any special requirements 



A. Ryff. 
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Martin-Denver Checkout System 
Meeting Attendees 


NAME 


LOCATION 


Dick Winckler 
Dick Stanley 
Gerald Boruski 
A. J. Monaco 
Bill Hess 
John Jones 
C. Brown 
Ted. Charbonneau 
Frank O'Rourke 
A1 R yff 
P. w. Melitz 
A. J. Albrecht 


Denver (Martin) 

VAFB - LA GEM 
Los Angeles - (5th Floor)FSD 
Los Angeles - Scientific 
Los Angeles - Scientific 
FSD 
MOL 
MOL 
MOL 
MOL 

Aerospace Industry Marketing 
Los Angeles - (5th Floor)FSD 
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AGENDA MEETING NOVEMBER 29, 1965 


Re: MARTIN - DENVER CHECKOUT SYSTEM 


1 . Discuss DIMAC concept as proposed by Martin-Denver and outlined 
in their specification from standpoint of status, problems, potential and 
value to,the IBM Corporation aerospace effort. 

2. Discuss the status of ETR study, stressing the schedules, present 
status and problems. 

3. Discuss the relationship of the proposed Martin check-out system 
with the contemplated VAFB check-out concept and approach. 

4. Discuss problem of general IBM support in these areas, from 
standpoint of what is needed to get the business. 


RESOLVE : 

1 . Size of proposal effort (if any) required for DIMAC, 

2. When the effort should start, how long it should last and what output is 
expected. 

3. Major problems in proposing on this system, including RFP date (con¬ 
templated), special equipment required, special program required and possible 
value, whose proposal FSD or DP? 

4. How the ETR effort should be handled, coordinated and staffed to meet 
present commitments, especially from standpoint of what manpower should be 
provided, 

Li 

5. Nam.es or numbers of IBM personnel required to handle present stage of 
these efforts, 

6 . The way both efforts, ETR, DIMAC, fit into the goals of the Los Angeles 
MOL project group. 

7. What are plans to handle expected hardware delivery problems from 
standpoint of standard and special hardware requirements. 
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TRIP REPORT CONCERNING TRIP TO WASHINGTON 
SYSTEM CENTER. BETHESDA, MD. 

PURPOSE: Discussion of possible DIMAC hardware configuration and 

recommendations for an eventual optimum configuration. 

DATE OF TRIP : 12 to 14 January, 1966. 

ATTENDEES: Val Adams, Bob Bruns, W.Gourlay, Jr., Joe Melville, 

Bob Moeller, Wes Peavy, Dick Rivett, A.L.Ryff, 

F.X.O'Rourke, C.P.Strive. R.T.Winckler. 

I. RESULTS : 

The discussions on 13 January, 1966, were primarily of a familiarization and 
educational nature and were, for the most part, accepted without significant 
technical comment by WSC personnel in attendance. 

On the whole, the WSC engineering group were not in a position at 
this time to go into any of the detailed design considerations related to a 
specific DIMAC configuration, which might be fabricated by them. 

After about 5-1/2 hours of engineering discussion, WSC personnel 
expressed a desire to cancel the engineering conference tentatively scheduled 
for the following day, to allow them time to consider and review data already 
presented and to more thoroughly discuss possible approaches with other WSC 
design engineers not in attendance. 
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It was agreed that a copy of the formal DIMAC system specification 
(currently scheduled for completion 25 January, 1966) would be forwarded 
to this group, prior to 1 February, 1966, for their use in configuring a 
hardware approach that would meet the overall system requirements. In this 
regard, WSC agreed to have an initial hardware approach defined for review 
and comment (together with an "area price") by March 15, 1966. The concept 
submitted would be one suitable for design and fabrication by FSD personnel 
at WSC. 

WSC is further planning to attempt a definition of a hardware approach 
for the PCM and DRS comparator channels required for implementation of the 
DIMAC configuration, utilizing 1800 processing equipment. This hardware 
would also be fabricated by FSD at WSC for eventual integration with the 1800 
systems. The date for this proposed configuration is also March 15, 1966. 

II. PLANNED ACTIONS : 

As a result of this meeting, the MOL Project Group will forward three copies 
of the final system specification, together with associated block diagrams and 
reference material to W. Peavy, WSC Bethesda, Md. 

R.T.Winckler of IBM,Denver, is planning to submit a formal RPQ to 
Poughkeepsie in parallel with the WSC effort, to determine what their approach 
to the ROS comparator concept would be, both from the standpoint of hardware 


Section 5.1 


Page H/54 
1/28/66 









IBM CONFIDENTIAL 


-3- 


configuration and their particular desire to fabricate this type of equipment 
in light of the scheduled nine month del^ for the DIMAC system. 

Further meetings are planned to be held with 1800 personnel (especially 
the group at San Jose) with regard to their implementing a special comparator 
unit for use in the 1800 system. 


REFERENCES: 

Detailed minutes of this meeting have been assembled. They completely 
document pertinent questions and comments presented during discussions on 
13 January, 1966. This document (34 pages) has been placed in the DIMAC 
conference file and is available, on request, by personnel associated with 


the project who may be interested in reviewing the detailed contents of the 


discussions. 


FXO'R:jh 



Distribution: 


G.Boruski, C.B.Brown, W.B.Gibson, 

W. Gourlay, Jr. ,J.E,Hamlin, W.Peavy,(4 copies) 
at WSC,Bethesda; A.L.Ryff, J.J,Selfridge, 

R.Winkler,IBM Denver (2 copies). Project File. 
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Date: 


From (Dept/Loc): 
^ ephone Ext.: 


January 17, 1966 
104 



Subject: Titan III ILC Schedule 


Reference: 


To: W. B. Gibson 



Mr. Kent Gunderson project engineer for DIMAC told me that the Phase II 
go ahead for the ILC has been postponed until September, 1966. It was 
originally to have been given in January. Martin is still pushing for early 
approval of the DIMAC concept so that procurement can start. My contacts 
in SSD tell me there will be no go ahead until the results from our study are 
available. 


R. E. Blue 

REB/cfc 

cc: R. W. Swanson 
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ACRONYMS FOR DIMAC 


AGE 

Aerospace Ground Equipment 

CST 

Combined Systems Test 

DIMAC 

Data Integration Malfunction Analysis Computer 

DRS 

Data Recording Set 

AFETR 

Eastern Test Range 

ILC 

Initial Launch Capability 

OCALA 

On-line Computer Analysis in Launch Assistance 

OGE 

Operating Ground Equipment 

OTTS 

OGE Test Tool Set 

PCM 

Pulse Code Modulation 

VAB 

Vehicle Assembly Building 

VAFB 

Vandenberg Air Force Base 

VECOS 

Vehicle Checkout Set 

AFWTR 

Western Test Range 
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Customer/Prospect Name (1) MARTIN-DENVER, Littleton. Colo. 4/19-20/66 (15) 

Individual(s) contacted (16) See below _(59) 

Your Name (60) W. Gourlav. Tr. _(70) Date (71) April 22, 1966 (76) 

Summary of Facts Covered: 

1. ATTENDEES : R. Winckler B. Pennington, et al 

F. O'Rourke 

W. Gourlay, Jr. 

K. Gajewski 

2. BACKGRQUND : B. Pennington, K. Gunderson and other Martin personnel 
have reviewed this group's preliminary specification for the Titan IIIC checkout 
system. The single copy in their possession was retrieved at this meeting. 

3. SIGNIFICANT ITEMS : 

a. Those Martin personnel present exhibited a positive interest in the 
ROS concept as described by K. Gajewski. 

b. Martin is now considering an initial factory-installed system to 
include active command/control functions. This is a departure from their 
previous idea of a simpler monitor and diagnostic complex. 

c. The PCM input rates are now expected to be 384 kbits/sec. rather 
than the 350 kb/sec. previously expected. Data synchronization would be 
provided by Martin. 

d. It was reaffirmed that the competitive cost comparisons would be made 
on the total system price (i.e., Martin-supplied equipment + vendor-supplied 
equipment). 

e. Martin expressed no major disagreement with our preliminary basic 
system configuration. They did, however, indicate that the initial purchased 
system would not include all the proposed equipment which can be provided as 
an expanded capability. However, this is in agreement with our basic modular 
approach and should not be interpreted as detrimental. 

f. USAF approval of the RPD is expected by Martin in the next two weeks. 
Funding for the RFP apparently will not be available until September, 1966, 
although the RFP would be issued sooner. The RPD as submitted by Martin is 
only for installation at the Denver facility, and will not, unless modified by 
USAF, include a system for Vandenberg AFB. 
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4, GENERAL COMMENTS: B. Pennington indicated a Martin willingness to 
provide the comparator front end in the event a vendor could not. The capability 
cf the ROS to do this job was explained, as well as its capability to tag all 
data. Martin intends to provide the system/ground station interface. 


WG:jh 

cc: Ca B, Brown 
K. Ga jew ski 
W, 3, Gibson 
R. Hippe 
Ja KlOtS 
Fa Mutz 

W. Peavey, Bethesda 
Bo Reynolds 
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Comparison of possible launch vehicle 
combinations using available systems and 
fluorinated Transtage. Scout is not shown. 
The Air Force is also interested in the 
Minuteman ICBM first stage as a launch 
vehicle. There is a good possibility that 
contracts will be let by the Air Force for 
investigations of the cost effectiveness of 
the Minuteman first stage as Minuteman 
Ts are phased out of the weapons inven¬ 
tory. Funding possibilities for such an 
effort look good, since the alternatives for 
the weapon’s stage I are destruction, 
planned storage or use as a boost vehicle. 


Launch VehscSes 





by John F. Judoe Discussions with Department of ment will emerge in the following five j 

Defense, Air Force and industry ex- years. 

Washington —The military launch ve- perts indicate that there is general The building-block approach taken 

hide stable is full. Every mission now agreement among all on the total lack by DOD over the past years has re- 

under serious consideration can be ful- of a requirement for an all-new launch suited in an almost fantastic seres of 

filled by existing and developmental vehicle system within the next five years possible upper- and lower-stage com- 

propulsion systems. —and few signs that such a require- binations, which can respond e :ually 


Combinations within the state of the art in the Titan III family tions are valid, but only the Titan 111-C combination is cut rently 

and other upper-stage systems. So-called “big-core” element is not funded. Other elements are funded as separate items l y the 

included in the defined core alternates shown. These configura- military or NASA. 
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v\j lor no: i-if.a.d., equatorial, syn- 
ehronous and deep-space military mis¬ 
sions. The major milch is that not all 
of these propulsion systems are opera¬ 
tional. The full stable will really come 
into being only if current programs are 
pursued with adequate funds. 

The military and NASA cooperate 
at both the working and management 
levels in booster and launch vehicle re¬ 
quirements arid technology. 

New cryogenics coming—New pro¬ 
pulsion concepts in large cryogenic 
chemical systems are being funded by 
the Air Force in the advanced develop¬ 
ment category with a Fiscal Year 1966 
allocation of S8 million and a proposed 
FY ’67 funding level of $6 million. 

Known as the High-Performance 
Cryogenic Pocket Technology Pro¬ 
gram, the effort involves two firms. 
Rocketdyne Div. of North American 
Aviation is investigating a 1,500-psi 
toroidal combustion chamber together 
with a chamber iap-off turbine drive 
and an altitude-compensating aero- 
spike-type nozzle. 

Pratt & Whitney Div. of United 
Aircraft ts researching a 3,000-psi 
transpiration-cooled combustion cham¬ 
ber, together with a topping cycle 
turbine drive combined with high-ex- 
pansion-ratio bell-type nozzles. 

The propellants in both cases are 
hydrogen and oxygen. Air Force intent 
is to develop the technology necessary 
for the engineering development of 
flight-weight engines in the 100,000- to 
500.000-lb.-thrust class. 

The engine modules ultimately de¬ 
veloped will be used either as single, 
high-energy upper-stage powerplants or 
in a variety of multiple-engine clusters 
to propel reusable launch vehicles. 

Just how far in the future this ulti¬ 
mate use will be can be understood by 
the reference to reusable launch vehi¬ 
cles. Most experts consider these to be 
essentially out of sight. 

Flight-weight nuclear reactor sys¬ 
tems—now being developed by NASA 
for its own propulsion missions—are 
not seen as likely candidates for mili¬ 
tary space missions, at least not those 
missions now on the planning boards. 

The Thor/Ablestar, Thor/ Agena D, 
thrust-augmented Thor , and the Atlas/ 
Agena D are all proven vehicles and 
handle almost all current military space 
launches. Most of these vehicles have a 
healthy future. Scout is a NASA-devel¬ 
oped booster used by the Air Force for 
specific missions. 

The building-block approach essen¬ 
tially involves the next generation of 
vehicles—based on the Titan vehicle 
and covering the large-solid zero stages 
as well as a combination of upper stages. 

The Titans —The Titan I1I-C, a 
Titan II storable liquid core slung be¬ 
tween two five-segment, 120-in., 1-mil- 



Boeing’s Burner II upper stage (Program 946), which is being considered by the Air Force 
for use in combinations of current propulsion systems proposed for deep-space missions. 
Burner II might also be used in launches into low-Earth orbit. Burner II has not yet been 
launch-tested. 


Possible applications of the Transtage unit in combination with NASA’s Saturn iB based 
on a Martin Co. performance projection. 
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STATUS 

CONFIGURATION 

CURRENT 

T III (B) 

T III-C 

5 SEG/IMP. T III (B) 

POTENTIAL 

\ 

7 SEG./UAP. T III (B) 

156 IN./IMP, T III (3) 


PAYLOAD WEIGHT LD 
100 N. Ml. EAST 


10 K 


30 K 


4Q K 


Low-Earth-Orbit launch vehicle building-block combinations as pictured by Mari in Co. 
planners. The Boeing Burner 11 stage could be added, as well as a Transtage, as 
propulsive elements. 


STATUS 


CONFIGURATION 


PAYLOAD WEIGHT (LB) 

4 K 6 K gK 10 K 12 - 




T III C 


PRESENT 


7 SEG./IMP. CORE/7RANST AGE 


POTENTIAL 


T III C/946 

5 SE G./T III (B)tCENTAUR 
7 SEG./IMP. CORE/TRANSTAGE 
7 SEG./IMP. T III (B)/CENTAUR 
IS 6 IN/IMP. 7 III (S)/CENTAUR 


Configurations within the building block possibilities designed to handle synchronous 
equatorial-orbit missions. The number 946 is that assigned to the Boeing Burner II. 


STATUS 


CONFIGURATION 


100 N. MJ. VELOCITY FT/SEC. 
40 K 5i) lk gCO 


T III C 


PRESENT 


7 SEG./IMP. CORE/TRANSTAGE 


! i 1 


T III C/946 


□ I 


155 IN/IMP. COF.E/CENTAUR /346 __ 11 

Deep-space missions within the reach of possible building-block combinations. Again, tin 
946 refers to the Burner II stage. All figures and combinations are Martin Co. projection: 
based on performance values developed within the propulsion systems that exist today 
The Transtage fluorine uprating is not part of this deep-space projection. 



lion-lb.-thrust solids, topped by a Titan 
II second stage and then the versatile 
Transtage, is now in flight testing. It is 
the first in the family since the Titan 
III-A (Titan lll-C core without solid 
zero stage) which, although flown, is 
considered a building block rather than 
a launch vehicle in its own right. 

Transtage troubles in past launches 
have been analyzed and Air Force ex¬ 
perts are convinced there are no design 
difficulties. Thus, the next Titan II1-C 
launch has been delayed for about three 
months while an intensive checkout pro¬ 
cedure is pursued. 

The next two Titan ///-type vehicles 
about to enter active development are 
the seven-segment 120-in.-dia. solid con¬ 
figuration chosen as the Manned Orbit¬ 
ing Laboratory launch vehicle, and a 
two- or three-segment 120-in.-solid zero- 
stage version for intermediate payloads. 
There is little doubt about its becoming 
operational. 

The Titan core used in these vehi¬ 
cles is essentially the same as the Titan 
II. An improvement program is now 
being initiated, however, to increase 
the nozzle expansion ratio for altitude 
starts, improve the injector design, and 
increase propellant capacity. These 
changes will be in the first stage and 
will result in significant performance 
increases at a relatively negligible cost. 
The current Titan III-C development 
cost is in the $900-million area and the 
improvements amount to only a small 
fraction of this. 

Mission analyses performed by the 
Martin Co., developer of the basic 
Titan vehicle, indicate that many mili¬ 
tary missions can be performed by us¬ 
ing various segmented 120-in.-solid and 
156-in.-solid zero stages combined with 
three core configurations topped by 
Transtage, Centaur or Agena propulsion 
systems. The studies also include using 
the Boeing Burner II (Program 946) 
as a fourth stage (see charts). 

Upper-stage combinations—Martin 
officials are convinced that the Transtage 
can be coupled to current fluorine tech¬ 
nology resulting in a new high-energy 
upper stage. The fluorine technology has 
been under development by Air Force 
and NASA for several years. Martin 
experts say it would be well worthwhile 
to start narrowing this effort to focus 
on such a vehicle as tho Transtage. 

Calculated performance levels in¬ 
volving all these combinations are com¬ 
paratively shown in. the accompaning 
charts.. 

In early Titan III planning, both 
Centaur and Agena upper stages were 
considered. The reasons for not actively 
pursuing these avenues were largely eco¬ 
nomic, although it was determined that 
both upper stages are feasible in com¬ 
bination with the current Titan III-C 
minus the Transtage. However, there 


7 SEG./UAP. CORE /TRAxNST AGE/346 
156 SEG./IMP. COBE/7P.ANS7AGE/046 
5 SEG./T II! B/CENTAUR/94S 
7 SEG./IMP. CORE/CENTAUR/946 


are no definite programs involving any 
of these combinations other than the 
current Titan III-C —the lower-seg¬ 
mented version, and the seven-segment 
configurations. 

But Centaur is being developed and 
is flying. Agena is a proven upper stage 
and Burner II is being designed and 
built by Boeing. Lockheed is now ap¬ 
proaching the Air Force with plans to 
uprate the Agena and move it into the 
Titan building-block series. 

The 156-in. solid rocket is now a 
technology program—subsisting on a 
DOD-imposed funding level of some $2 
million per year. At least this is the level 
planned for the next fiscal year. 

There are no stated missions for the 


156-in. system as a strap-on. The cur 
rent funding level is deemed toe lov 
even for a technology program by every 
body except DOD. In spite of its appar 
ent lack of mission, the big solid stil 
has a strong potential for the Titan II 
program and this application is mos 
likely to be the one that moves it ou 
of the doldrums. 

The constant ha-ping on niissi ms a 
justification for the development i-f an 
of the launch vehicle combination 1 cites 
often obscures the cost factor—ar d thi 
is a real factor. Air Force and in iustr 
are fully aware of this and ever; cor 
cept is now being approached rm re o 
a cost basis rather than any assunptio 
of possible missions. 

missiles and rockets. May 30, 196 
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CUSTOMER NAME: 


Philco, WDL 
3875 Fabian Way 
Palo Alto, California 


REGION: 


Western 


DISTRICT: 


16 


BRANCH: 


San Jose 


BRANCH MANAGER: 


MARKETING MANAGER: 


SALESMAN: 


SYSTEMS ENGINEER: 


E. H. Dohrmann 


J. Doyle 


V. Ziogas 
R. Clark 


I. Wentzien 
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A. Customer Organization 

1. Personnel -- All of the following personnel are in the 
project management office. 

D. M . Rowell 
J . L. Abbott 
S . W. Teicher 
J. Corsiglia 
W. C. Slagle 
T. Easley 

Individual titles are unknown. Initial contact was made 
at the request of S. Teicher who recently returned to WDL 
from Tech. Rep. Division of Philco. In his position in 
Tech. Rep. , Teicher ordered an IBM 1130 to replace a 
GE 225 at El Centro Parachute Test Range. 

J. Abbott was the project engineer who recommended a 
CDC 3100 for the operations center at Pt. Magoo. This 
decision was reversed by Navy personnel and a 360/40 
is presently being installed at this location. 
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B. Background 

1. Philco WDL presently has the O & M contract on 
five of the eight remote sites of the SCF and I & C 

at all sites. Presumably these facilities will be used 
to support MOL. 

WDL has also been active in support of NASA in Houston. 

From an equipment standpoint Philco makes equipment 
for both the vehicles and satellite tracking equipment. 

2. There is presently no IBM equipment (outside of U/R) 
installed in WDL. The computer presently used by the 
facility is a Philco 212. 
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C. Current Status 

1. Philco is interested in MOL because of their connection 
with SCF. No RFPs will be released by Philco and as a 
result all contacts with this customer have been advisory 
in nature, i.e., 360/44, 360/67 presentations. 

The hardware has been well received by Philco personnel, 
particularly the 360/67 and its organization. The price 
on this system did have a detremental effect on their 
attitude however. 
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D. Problem Areas 

Points of discussion that have come up in our talks with 

Philco that may indicate hardware problems: 

1) Availability of a channel that would allow external 
addressing of memory with identifying bits from the 
telemetry work. 

2) Shared memory is desired although it isn't considered 
necessary. 

3) 360 hardware costs may be high. 
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E. IBM Strategy 

1. Sales Action Program 

Continue our advisory program. Provide any possible 
coordination between Philco WDL and MOL Project 
Office. Philco is primarily interested in the following 
phases of the remote site facilities: 

a. Software 

b. Integration 

c. Operation 

2. Technical Help Required 

None at present. Future demands may come in details 
of satellite control and data handling that may require 
assistance from MOL Project Office. 

3. IBM System Design 

No formalized design. A dual 360/44 system has been 
suggested to Philco. 
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G. Competition 

1. Primary competition is CDC. (Probably 3300.) Philco 
has not eliminated the possibility of the sole source 
procurement for the remote site hardware. There has 
been no discussion by Philco personnel of advantages 
or disadvantages of IBM vs CDC. 
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MOL STANDARDIZED CALL/TRIP REPORT (IBM CONFIDENTIAL) 


Customer/Prospect Name (1) Philco Corporation - Western Development Lab (15) 

Individual (s) contacted (16) Sheldon Tiecher and Tack Corsiglil _(59) 

Your name (60) W. B. Gibson _(70) Date (71) March 31, 1966 (76) 

T. M. Charbonneau 
Summary of Facts Covered: 

This visit was made in support of the San Jose Branch Office. Branch attendees 
were: 

Vince Ziogas 
Irv Wentzien 
Rich Clark 
John Doyle 

The customer was interested in securing technical information regarding the 360 
Mod. 44. This information was required in great detail. Philco, represented by 
Sheldon Tiecher, was only interested in discussing equipment requirements at 
Remote Sites. It is interesting to note that they at no time discussed Satellite 
Tracking Center equipment with any IBM personnel, indicating that: 

1. They do not believe that this will be in the RFP, or 

2. They believe someone other than IBM has the business. 

Philco's prime comments regarding Model 44's were: 

1. It appears to be the best IBM system for the job. 

2. They are concerned about the lack of an IBM-furnished multi-programming 
monitor and were vocal in pointing out that other competitors supplied 
this. 

3. In equipment configuration, they asked us if price included significant 
amounts of magnetic tape and card/printer Input/Output. When queried 
on the need for this, they stated that the administrative work at the 
Sites required this equipment. 

Follow-up calls will be made by the Branch to supply additional technical 
assistance. 

By copy of this report, I am asking Charlie Brown to work with Bob Krause and 
Jim Selfridge to determine the rental of the installed administrative equipment 
at each Remote Site and to see that this is adequately considered in our proposal. 


W. B 0 Gibson 


cc: C. B. Brown, J. J. Doyle 

R. G. Krause, J. J. Selfridge 
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CUSTOMER NAME: 


Lockheed Missiles and Space Co. 
P.O, Box 504, Sunnyvale, Calif. 
Telephone: 742-7151 


REGION: 


Western 


DISTRICT 


16 



BRANCH: 


BRANCH MANAGER: 


ACCT. MKTG. MANAGER: 


ACCT. REPRESENTATIVES: 


San Jose 


E. H. Dohrmann 


W. G. Burke 


C. R. Springer 
J. L. Spivack 


FSD REPRESENTATIVES: 


A. Peckar 
John Bridges 
G. McClure 
R. Strayer 


C 
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B. 1 


Section 5.4 


Historical Background - Lockheed MSC role in the MOL Project 
and related IBM marketing effort - 

a . Primary MOL Proposal Effort 

This effort started September 1964 with a nucleus of key 
LMSC people and grew to a peak level of over 600 in 
June 1965. After it was announced that Douglas had won 
the competition, this organization quickly disbanded except 
for a small group seeking to market MOL technology to NASA. 

Contacts: S. Edwards 

R. B. Gangstad 
H. Breen 
B. Bayuk 
E. Lennon 

IBM calls on the customer started early in the program, 
these calls and presentations were made to (1) develop 
contacts, (2) market standard computer equipment for ground 
data processing, and (3) market "off the shelf" airborne type 
computers via FSD. (This third effort was in cooperation with 
LMSC requests but was necessarily restricted since FSD had 
already teamed with Douglas Aircraft on a competitive proposal.) 

b. MOL Ground Data Processing Proposal 

Contacts: J. Carrol 

W. Reinhold 
R. L. Richman 

As a side effort to the primary proposal, a group within 
Lockheed went after an expansion to the Satellite Control 
Facility (Sunnyvale) to support MOL. Cooperative effort 
in this area from January 1965 led to a presentation in March 
1965 involving a duplexed 360/50 configuration with graphics 
and 1800's. Lockheed liked this configuration and went to the 
Air Force with it. The Air Force eventually directed that any 
extensions in capability to the SCF (as well as the facility at 
Cape Kennedy) would be in the CDC-3 600 area. At this point 
this effort was discontinued by Lockheed. 
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c. Command and Control Proposal 

Contacts: D. Harris 

J. Hooper 
D. McClinton 
T. Dewey 
M. Feldstein 

In mid-August 1965, a large unsolicited proposal effort 
was underway (Lockheed proprietary) to entirely revise 
the Satellite Control Facility (SCF) at Sunnyvale. As 
part of this effort, a large time sharing complex was 
configured and priced by mid-September for LocKheed. 

While the computing configuration was large ($265,000 rental, 
$11.8 million purchase) its cost was only a small part of the 
total cost of the LMSC system proposal. The configuration 
included (3) 360/67, (5) 2065, 40 (2250 II), 40 (2260), 2280, 
drums, disks, 2314's and other supporting I/O equipment. 
Implementation was tentatively slated to take place starting 
between late 1966 and 1970. 

This project, in this particular context, has been in a 
dormant status since Lockheed's presentations to the USAF. 
The effort to revise SCF has not disappeared; however, it 
has taken some new forms over the past few months as 
described below in C. 2. 

d. From a strategy and sensitivity standpoint, it is also 
important to consider the historical background of the 
461 Project which precedes the MOL project by several 
years and is in some ways related. This is a classified 
project on which several studies have been made recently 
involving large System/360 computer systems. 
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B. 2 


Section 5.4 


Installed IBM Equipment 

The following systems are now installed: 

Three IBM 7094's; two of which are purchased 
Two IBM 1410 
Two IBM 1401 
Three IBM 360/30 

Several other IBM 360's (including a Model 40 and 50) are planned 
for installation in 1966 replacing the two 1410's and last 1401 as well 
as discontinuance of the rental 7094 system. 
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C. 

C. 1 

C. 2 


Section 5.4 


CURRENT STATUS 


No formal proposals are outstanding at this time; however 
the most recent configuration for the 461 Project is very- 
active now. Iterations with the customer are currently 
underway leading to a firm proposal. 

Other Active Projects 


a. Interim Extension to SCF and SCOSS Project 


Contacts; 


T. Dewey 
P. Failer 
R. Pitch 
J. Baker 
D. McClinton 
V. Olsen 


Project Manager 
SCOSS 

Extension to SCF 
Extension to SCF 
C & C 

Aerospace Corporation 


These two projects are related to Item B. 1 (c) described 
above. 


Extension to SCF - Lockheed has the job of integrating IBM 
2250 displays into the existing Satellite Control Facility 
(Sunnyvale). Local sales effort has been in the form of calls 
and presentations relating to System/360, the IBM 2250 displays, 
graphic film units, and physical planning. The 2250 display 
was demonstrated to Lockheed at the FJCC at the same time 
as the Aerospace Corporation and USAF representatives. 

Information has been provided locally on tying an IBM 2250 to 
a CDC 160 computer. 

This effort is essentially directed from the Aerospace Corporation 
and the equipment will be ordered there. Therefore, local IBM 
effort is supportive in nature to the principal thrust taking place at 
the Aerospace Corporation account as coordinated by the IBM MOL 
Project group. 

SCOSS , This project is entirely of Lockheed origin and is in 
a conceptual stage at this time. The purpose of the SCOSS 
project is to design and implement aSatellite Checkout System 
here at Sunnyvale for SCF. This project does hold some potential 
for an On-site System/360 with graphic data processing equipment. 
Equipment would be ordered locally. 
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b. VAFB Computer Facility 

A new effort is being started now to propose a redesigned 
Vandenberg AFB facility. This effort is by the LMSC personnel 
at Vandenberg as assisted by the Sunnyvale Information Proces¬ 
sing Organization (A. Cordvan, W. Grundherr.) This complex 
will involve about 6-8 computers and will probably be 8-10 
times as powerful as the existing facility. This checkout and 
tracking facility will support MOL shots as well as the other 
Usual VAFB test activity. Completion of the proposal effort 
will be in about March 1966 with equipment delivery about 4Q66. 
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SCF REPORT 


1. CONTRACT STATUS 

a. Lockheed has I & C and O & M contracts on the Satellite Test 
Annex which includes the bird buffer area. The O & M contract 
will last to 1967. The I & C contract(s) are being added to by 
such efforts as the Extended SCF Capability and SCOSS at this 
time, but their exact duration is not yet known. 

b. Verification of Contract Status Summary 


Remote 

Sites 

. 

Kodiak 

Indian 

Ocean 

New 

Hamp¬ 

shire 

Classi¬ 

fied 

VAFB 

Hawaii 

Satellite 
Tracking 
Center & 

BB 

I & C 

Philco 

Philco 

Philco 

Philco 

Philco Philco 

LMSC 

O & M 

LMSC 

Philco 

Philco 

Philco 

LMSC 

! LMSC 

LMSC 


2. Dollar value of Lockheed*s contract is considered LMSC proprietary 
information. There are several contracts however and two are thought 
to be in excess of 50 million exclusive of equipment. Total contracts 
are believed to be well in excess of 100 million dollars. 

3. The Air Force relies heavily on Lockheed for technical help but LMSC is 
aware that they are just contracting labor and have a fairly unsatisfying 
type of subordinate job. Unfortunately for LMSC, the local Air Force 
people have limited influence in new system designs and equipment 
selection. 

4. Lockheed realizes that its goal of more systems integration business in 
this area (as well as its present business) is threatened by the possibility 
that the Air Force will furnish more large CDC computers (from 3300s to 
6400/6600) as GFE. The best approach for Lockheed seems to be to 
promote some new business in this area by improving capability with new 
system designs in limited areas and gradually expanding them from that 
point. SCOSS is the prime example of this apparent strategy and is 
described in (5). The upgrading of the bird buffer area is another area 
and LMSC already has people at work on this area even though they refuse 
to discuss it openly. 
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5. SCOSS 

This project is entirely of Lockheed origin and the plan has been submitted 
to the Air Force. Contract go ahead expected by 2/15 - 3/15/66. Equipment 
will be ordered by 2 to 3 months with installation in 3 - 4 Q 1966. Equipment 
potential ranges from 1 to 3 displays possibly with a small S/360 with files. 

SCOSS is a systems checkout, control, status, and scheduling system for 
the entire STC data system. Lockheed will furnish the checkout, control, 
and switching part of it and will put this system together with the existent 
SDC schedule and status information from the common data pool. Data for 
the data system checkout and control will be extracted from all parts of the 
system via any designated 160A in the bird buffer area. All computers would 
be tapped for this type of information. The information from SCOSS would be 
used to increase the efficiency and management control over the STC data 
system. It is a perfect entry point for future effort on the bird buffer area. 
(See Figure 1). 

6. Mellonics is not included in all discussions by LMSC. These people are 
partitioned-off in the application area. For example, they are being told 
to look at their programming chore as being largely machine independent. 


Section 5.4 


Page C/4 
2/18/66 




























IBM CONFIDENTIAL 


D. 

D.l 

D. 2 


D. 3 


Section 5 


PROBLEM AREAS 

The principal problem at this point seems to be hardware 
delivery, particularly of 360/65 and 44*s and 22 50 displays. 
Special interface equipment could also cause delivery 
problems. 

The specialized programming requirements of these projects 
and the intentions of the customer or FSD to supply certain 
real time control programs makes a definitive estimation of 
O/S 360 requirements difficult. It does seem clear, however, 
that on-schedule availability of parts of O/S 360 along with 
graphic support will be important to our selling efforts. More 
investigation is needed in this area, along with consideration 
for supporting shared memory for 360/65 and/or possibly 
support for bulk core as an I/O device. 

Special hardware design yielding significant cost advantages 
should be studied further such as combination of 2701 data 
adapters (some of which will have special performance charac¬ 
teristics), special PCM interfaces, and switching equipment. 
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E. IBM STRATEGY 

a. Interim Extension to Satellite Control Facility 

Currently providing local support for the work Lockheed is doing 
for Aerospace Corporation account. (Ref. C.2 (a)) 

b. SCQSS 

Actively assisting this area. At this time nocompetitive activity 
yet identified. 


c. VAFB Proposal 

Additional information will be gathered on this project in the 
next few weeks which will permit the development of a specific 
plan of action. The configuration developed locally will be 
closely coordinated with the IBM MOL Project in order to 
develop the strongest possible proposal. 
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G. COMPETITION 

The principal competition for this work is expected from 
CDC and UNIVAC. For the Extension to the SCF, Vanden- 
berg Proposal and SCOSS Project, CDC appears to be a 
slightly stronger competitor than UNIVAC. The computers 
will probably be the CDC 6400 and 3100. CDC has its own 
graphic displays and alphameric displays along with a 
Data Display Recorder. In the case of UNIVAC, the 1108-1 
and 1108-11 will probably be used for the larger machines 
with 490 computer used for front end work. UNIVAC has 
currently been making presentations locally with IDI (Infor¬ 
mation Displays, Incorporated) which is a change from its 
previous reliance on DEC (PDP) displays. 


Section 5.4 


Page G/l 

1/21/66 







IBM CONFIDENTIAL 


Call on LMSC February 2, 1966 


X. LMSC Attendees 

J. V .plummer - Vice President and Assistant General Manager 

R. C* Kent - Assistant General Manager, Military Programs 

N. Tabor - Manager Network Integration 

Tom Dewey - Senior Staff Engineer 

Walt Schuman - Project Marketing to SCF 


2. Topics: 

A. Introduction 

B. Mutual Interest in SCF 

Computing RFP 
Systems RFP 

V hat Does LMSC Think These Are 

C. Potential Mutual Interests, LMSC and IBM 

D. LMSC Current Posture in SCF 

C & M 
I & C 

E. V or king Arrangement prior to RFP 

Not formal until RFP structure is firm 
Determine Std and Special Hardware REC 
Make a mock proposal 

Free interchange of information - but keep proprietory 

F. Meilonics Influence 

G. LMSC - IBM 

Other extension - e*g. WTR 

K. Conclude with Specific Plan for Action 
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February 3, 1966 


DEBRIEF ON LMSC CALL OF FEBRUARY 2, 1966 


The attendees are as given in the planned agenda, which was followed 
almost explicitly. 

NOTES - Plummer gave rundown on LMSC organization - showing Kent 
being in charge of Special Projects. Hamlin and Kent could be considered 
as counterparts. I deem Kent to be good leading performer to whom 
Plummer delegates project responsibility after policy level questions are 
settled. There is no doubt but that LMSC recognizes that their business 
interests would be enhanced by claiming working relationship with IBM. 

I deem they are reluctant to commit to work exclusively with IBM at this 
time. Kent seems eager to cooperate. LMSC is, however, quite desirous 
to be systems integrator and to be in charge of systems engineering. 

Tabor then conducted briefing regarding STC (and SCF). He gave expected 
contract structure as: 



Communications - open 
Command and Displays — 
S of twar e -- 


u 

O 

+j 

fd 

u 

tj) 

CD 

+j 

G 

i—i 

co 

S 

CD 

+J 

CO 


Hardware (Computing and Special) >. 

CO 


We covered present LMSC "R & D” work scopes as: 

1. Integration (augment to Aerospace) 


A. 


B. 


Section 5.4 


2. Detailed systems engineering, advanced 
planning, configuration control, i.e. 375 

3. Installation and Checkout 

4. Operations and Maintenance 


Associate Contractor to buy or build STC 
equipments 
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In conversation he mentioned misue of communications gear as to why 
Integration contractor will get into this area end that system upgrade 
will use 4800 bits/sec.facilities. 

We discussed WTR FEC contract area. Lockheed Electronics will bid 
supported by LMSC and Lockheed Field Service. 

They expressed great interest in TMCC and talked of knowing Colonel 
Newton and Greede (SP). 

Dewey mentioned security problem in Communications area. 

We spent some time describing function and interests of FSD to allay possible 
LMSC concern on our rdle. We explained that our interest extended only 
to assuring that computing systems - and first functional level of 
connecting subsystems were IBM responsibilities - perhaps with LMSC 
quality control or system assurance role. 

Schuman - is not a strong leader. 

Dewey is important from technical and history relationship to STC. 

Tabor seems competent - his participation is hard to estimate. 

They discussed money limitations and indicated Control Center extension 
at Sunnyvale. 

Tabor talked of organizations (WTR and SCF) competition for money and 
fear of SPO dictates. 

Tabor discussed short-term expansion plan and long-term expansion plan - 
the latter being the final Control Center configuration. 

LMSC considers STC and RTS being inter-related and contractually together. 

We didn't probe this because of Philco vs. LMSC contractual sensitivity. 

Their discussion on Mellonics did not impress me that they considered 
Mellonics critical in system implementation performance. They acknowledged 
Mellonics software competence. 

Tabor is concerned on 375 specification requirements - he discussed 
handicap of complying wherein rental devices are in the system. 

They did not provide any information on Dispay (2250) implementation. 
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We agreed to further consideration by both Companies. 

We discussed further investigation and thinking. Plummer mentioned 
their laying down their work scope interest which could then be compared 
with ours in the next meeting, scheduled for February 11, 1966. 

We mentioned and briefly discussed checkout systems and our contacts 
with Martin and Douglas. 

In departing, I mentioned mis sion planning and short turnaround for 
contingencies. 


J. E. Hamlin 

JEH:jh 
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MOL STANDARDIZED CALL/TRIP REPORT 

Customer/Prospect Name (1) Lockheed Missiles and Space Corporation (15) 

Individual(s) contacted (16) See Below _(59) 

Your Name (60) M. B. Needle _(70) Date (71) 4/27/66 _(76) 

Summary of Facts Covered: 


On April 26, a 3-hour technical presentation was made to the following people: 
P. A. Fialer 

S. K. Lynch (Mellonics) 

D. M, Paige 

K. H. Powell 
A. F, Menter 
R. E, Anglim 
C. K. Nakata 
J. T. Carroll 

T. Dewey 

C. R. Springer (IBM) 

In addition, there was some discussion with T. Dewey on the Model 44 
Shared-Memory design for the RTS. 

/y/ 

'P'p# Vr 

M. B. Needle 


MBN/lr 

cc: W. B. Gibson 
C , B. Brown 
J. J. Self ridge 
C. R. Springer, San Jose 
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CHECKOUT 


160A Main Frame 

3 

2250 

6750 

166-2 Printers 

5 

690 

3450 

169-2 Memories (1SK) 

8 

2000 

6000 

167 Card Readers 

1 

460- 

460 

603 Tape Drives 

12 

550 

6600 

161 On-Line Typewriter 

3 

262 

786 

162-3 Data Synchronizer 

3 

600 

1800 


Total SPC/CPDC RTS INSTALLATION : 25846 *25, 846 

**297,874 


STC - PERIPHERAL SUPPORT COMPUTERS 

(2 - 610A’s) - Approximate Figure: *13, 064 

**310,938 


AF/CPDC PERIPHERAL SUPPORT COMPUTERS 

(2 - 160A's) - Approximate Figure: *14, 000 

**324,938 


Section 5. 5 


Page B. 2/1 
12/20/65 




April 5, 1966 


TO: J. E. Hamlin 

FROM: J. J. Selfridge IBM CONFIDENTIAL 

SUBJECT: IBM Position with Respect to SDC on the AFSCF 

The position IBM will take with respect to the Systems Development Corporation 
on the forthcoming AFSCF Advanced Data System bid and the follow-on contract is: 

1. IBM will not compete with SDC but will develop a plan explaining our 
method of operation and relationship with SDC in their role as Software 
Integration Contractor for use in the proposal. 

2. IBM will not plan on using them as a subcontractor to assist in the software 
development. This would present an in-house conflict of interest within 
SDC relative to their integration role. This latter, I believe, is their 
viewpoint. 

3. IBM will, through calls and briefings, make clear to SDC our position 
in (1) above. 

4. IBM will brief SDC management on our technical design and attempt to 
obtain their understanding, agreement with and support of that design. 

Such calls should be limited to those who, we believe, would respect 
our proprietary data. 

This position is based on SDC's past and present role and their future role 
which are discussed under those headings. Any discussion of SDC's role 
should consider the method the Air Force uses to control programs in the system. 
This is known as the Program Milestone System, AFSSD Document 61-47. 

Briefly, there are 8 Milestone documents: 


Milestone 1: 

Milestone 2: 

Milestone 3: 
Milestone 4: 
Milestone 5: 


Milestone 6 
Milestone 7 
Milestone 8 


An operational support requirement based on 
SCF user needs. 

An operational support plan based on programming 
support to be provided. 

A program design specification. 

Detailed coding specifications and flow charts. 
Consists of 2 parts: (1) Program decks, assembly 
listings, etc. (2) Documentation: (a) program 

description, (b) test specifications, (c) test results, 
(d) program operating instructions 
System Test Specifications and Acceptance Criteria 
System operating procedures 

Delivered System, deficiencies, interfaces, etc. 
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As Integration Contractor, SDC performed Milestones 2, 6, 7 and 8. System 
software contractors, Mellonics, DDI, etc., are responsible for Milestones 
3,4, and 5, and assist on 6, 7 and 8. 

SDC's Past and Present Role 


Since approximately 1961, SDC has performed a software subsystems integration 
role for the AFSSD on the AFSCF. They also performed some of the program 
systems and applications development, production and installation. At the 
present time SDC has: 

o Approximately 220 people working on the AFSCF in the following 

categories; Administration and technical staff (10); 3600 Programs (50); 
Requirements Analysis and Design (50); Bird Buffer and Tracking Station 
Program (40); Computing Facility, Training and Field Support (60). 

o Primary responsibility for Milestones 3, 6 and 7—although as can be 
seen from the immediately preceding point, SDC does development 
and production work. 

o Responsibility for producing control programs and utility system; 
i.e., SDC is producing a 3600 JOVIAL Compiler and rewrites all 
CDC supplied software. 

o Responsibility for operating the Computer Program Development 

Facility; and for maintaining all program documentation, specifications, 
test material, tapes, listings, etc. 

o Developed the Program Milestone System for the Air Force. 

o A built-in technical facility for support of the AFSCF, the use of which 
cannot be discussed in this memorandum due to its classified nature. 

o An administrative function for AFSSD to maintain status and usage of 
computing equipment throughout the SCF for billing purposes. 

SDC's Future Role 


The specific role of SDC cannot be determined at this time because of conflicting 
attitudes, ambitions, and the absence of clear directives in the Air Force, 
Aerospace and SDC relative to SDC. It is the intent of SSD that SDC's role be 
limited to only those factors which are the province of a not-for-profit software 
contractor. Some AFSSD people would say there isn't anything industry 
couldn't do working under Aerospace, while others assume that most software 
should be in-house. 
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Factors which have been considered in developing the IBM position are: 

o SSD let the Orbit/Ephemeric Subsystem contract early this year to 
Aeroneutronic and DDI with SDC having the integration role. SDC 
wanted a stronger role. 

o AFSSD has stated that the SDC contract will be limited to software 
integration. 

o Some Aerospace management people would like to see SDC out of the 
system since they present competition to Aerospace. 

o SDC may compete for software contracts, although theoretically they 
would not compete where they had a prior not-for-profit role. 

o SDC has supported the Air Force Operations people in the field and 
has won their respect. Operations would try to keep SDC in the 
system since SSD and Aerospace are looked on by the field as people 
who don't stay around to make the system work. 

o SDC first and second line management will resist cutting back on 
their program development and production work; and would prefer a 
weak software/hardware contractor on the ADS to help maintain 
their present position. 

o SDC has assisted in developing software specifications for the RFP, 
and SDC will help AFSSD in the evaluation of software designs. 

From many discussions I have had with Air Force, Aerospace, SDC and our own 
people with SDC experience, it is clear that the AF has net arrived at a firm 
position. I have heard that a directive on the role of not-for-profits is due 
out soon from Dr. Brown's office. This directive may clarify the position. 

I believe that SDC's role cannot change drastically over the next several years, 
and we should develop plans based on their having a systems integration role. 


JJS/jh J. J. Selfridge 

cc: C. B. Brown 
J. Klotz 
R. Krause 
G. McClure 
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MOL PROJECT SECURITY 

Sorr.e of the material used or generated in the MOL Preproposal effort is classi¬ 
fied and is to.be .kept in the Project Safe when not in use, according to 
the accepted ' IBM security procedures.. 

The project safe must not be left opened when unattended. All documents 
including working papers must be signed out and signed in. A log book is 
kept at ihe safe for this purpose. 

No security instructions have been received from, the Air Force on this program 
since we are in a preproposal stage. Therefore, the following in-house rules 
will be in effect: 

I) All working papers that are classified will be kept in a folder or binder 
that is suitably labeled on front and back. 

2} Information taken from a non-IBlVi document that is on a page labeled with 
•a classification will be considered classified unless it is also found in its 
entirety in open non-IBM literature. 

3) In case of any doubt as to whether an, unciassifiec page is valid, the open 
literature source should be cited on the information. 

4) Information taken from an IBM document that is on a page with a classifica¬ 
tion will be considered classified unless it is also found in its entirety in 
open non-IBM literature. If advisable, the source should be cited as in 
(3) above. 

5) Information from an IBM document that is not labeled with a classification, 
but is known to be classified, will be so classified by the user. The 
original IBM document in this case will not be reclassified as part of the 
MOL preproposal effort. If there is an office procedure for these cases., 

it will be followed. 
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5) The Air Force will be requested to issue security instructions prior to 
the commencement of activities by this office in the preparation of an 
unsolicited proposal or the answering of an RFP. 

7) When information is received verbally from such sources as IBM 
employees. Air Force, Aerospace Corporation and defense contractors, 
the security classification should also be requested. 

8) No discussions of classified MOL material is to be carried on with 
anyone without ascertaining their clearance and their need to know. 

The same procedure must be followed when disclosing written materail. 

8) Ail participates should take the deplorable acoustical situation of the 
office into account when discussing classified matters. 

10) The general security regulations regarding blackboards, transmission 
of data, registry of finished documents, receipts of documents and 
destruction of data apply in this case. 

11) Further information, on Security Procedures may be directed to the 
MOL Project Office. 
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Suggested Reading - List 


AIR FORCE REGULATIONS NO. 300-2, 300-3, 300-7. 

These documents are concerned with procurement of 
ADPE equipment in the Air Force. 
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